コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『アーキテクチャ ディスカッション Vol.1』に行ってきたよメモ

行ってきたメモ

アーキテクチャ ディスカッション Vol.1に傍聴席サイドで行ってきましたのでそのメモ。

トークの話題別まとめ

ディスカッション形式だったので、話題ごとにまとめてみました。 今回のねらいとしてはクリーンアーキテクチャの導入事例、成功した話、表に出にくい失敗した話などを語りたい、という回でした。

データのモデリングってどうしてる？

話のテーマとしてRDBのテーブル設計とデータのモデリングというのをどうしているかという話があった

アプローチに関しては…

などがあがりました。

また、データを分析するときの考え方として…

  • ドメインモデリングという言葉を使って、DBのモデリングとは異なるということを意識させる
  • 付箋での単語の割り出しや業務の重要なポイントを割り出して分析を行っていく

などのやり方の話もあがりました。

また、これらのベースの力をつけるために図書館アプリを作るという例をあげて「図書館といえば貸し借り」「だが会社としての着目点は『本の資産管理』である」「なのでドメインは『在庫管理』や『資産管理』が着目点になる」という考え方の練習法などが紹介された

クリーンアーキテクチャを採用した例と体験談

nrs(@nrslib)さんによる体験談とそれに対する質問。

クリーンアーキテクチャの右下の図 がデータの流れを表しておりだいたいこの形式に落ち着いた。MVCフレームワークと共存させる場合は非同期処理が不要という観点からPresenterが不要になる。

「Presnterは日付オブジェクトから日付文字列への変換などをする形でテストしやすいものとしにくいものを分けるために必要では？」という話になったらDTO（Data Transfer Object）を用意していたので、今回の事例の場合はその点は不要だった。

関連リンク

クリーンアーキテクチャの教育

手順化すると何も考えずにやってしまう人が多くなってしまうがその点どうしているかという話から布教の話題に。いろいろな体験談があがり…

  • アーキテクチャの冗長性を担保をプログラマーの自主性に任せるのは難しいので、考え方を伝える会を数回に分けて設けて生成ツールを提供したという話
  • 作業としては単純にファイルが増える作業ではあり、伝えてから良い感触が得られるまでのスパンが長いので、民主主義な流れになるとうまくいかないことが多いという体験談
  • 進化的アーキテクチャの文脈で、check style という静的解析ツールを一枚噛ませることで、依存関係的にご法度なものを防いだり、コードレビューでその点を充填的に見るなどの実践的なアプローチ

などなどが上がりました。

関連リンク

Ripository

何をデータとして渡すか

Entityを渡す、という設計で組む話が多く、Entityを渡してRipository内で差分をチェックしてRDBに書き込むという作業をしていたがつらい、などの話が出た。Entity Frameworkにおまかせすることで簡易化するという話もあがった。

更新と参照をどう表現するか

ケースバイケースだったが、以下のような話があがった。

  • 単純にテーブルのデータを取得したい場合はクエリを発行してそのまま渡すという考え方もある
  • 参照するものが異なるケース（ElasticSearchとRDBなど）があるので、レイヤーとして同一のものを挟んで運用する
  • ドメインに入れたくないデータは別途違う橋渡し方法を考える

参考リンク

開発での向き合い方、取り組み方

コミュニケーションと言葉

クリーンアーキテクチャなどを実践していくと、どうしてもドメイン分析が入ってきてコミュニケーションをとっていくことが必要になってくる。

その中でユビキタス言語を整理していくと、どうしても英語だと表現しにくいものが出てくる、そこで無理に英語を使わず、部分的に日本語表現するのも1つの方法論としてはありという意見がでた。

学び方

どうやって学ぶべきか、という観点になり…

  • 新人さんには社内用にDDD教育プログラムがある、1ヶ月やってもらうことで、理解しているかは別としてコピペできるレベルには至ることで学ぶトリガーをつくっている
  • RSSリーダーのような鉄板のテーマで実装して、いろいろなアーキテクチャで作ることにより差分などを感じ取りやすくなる

チームとしての進め方

  • 肌感のようなものは埋まるものではないので、ある程度大きな枠組みは整理して提供して、チームメンバーと一緒にやることで相互理解や、チームに合わない部分は軌道修正する
  • 古い手法と新しい手法が混在するコードに関しては、コードレビューや一緒にリファクタすることで軌道修正をかける

あなたが設計に興味を持ったのは、どこから？

設計というジャンルに興味を持ったきっかけを三者三様に話があがり…

  • 長年続くサービスのあるべき姿をどうにかするために設計を学びたい
  • 自らクソコードを生み出したので、その反省をもとにどうすれば良いものになるのかというところから
  • データモデリングの文脈で、時代的背景もあり、オブジェクト指向などの流れから自然と出会い
  • 既存の巨大なコードを相手にするときに、自身の責任範囲ではないことを明確に説明するための材料として
  • 炎上案件を正しくしたいということへのアプローチをするために
  • ひとつのファイルに詰め込まれたコードを分解するため、生き残るために

などなどのバックグラウンドが語られた

クリーンアーキテクチャを適応するところ、できないところ

  • クリーンアーキテクチャは万能ではない
  • 業務的な複雑さと技術的な複雑さがあるが、前者の場合は有効だが、後者の場合はパフォーマンスなどを考える必要があるため必ずしも有効ではない
  • ただ、前提知識として持った状態で取り組むと取り組まないでは大きな差になる。

DRY原則に関して

クリーンアーキテクチャの本に取り上げられていた「本物の重複・偶然の重複」という部分からDRY原則の話になった。

  • DRYを実践することで見えるものがあるので、はじめから怖がってはいけない
  • 技術的な重複はDRYでまとめるべきだが、ビジネスロジックとしての重複は気をつけて考えるべき（特に境界づけられたコンテキストを跨いでいないか、など）

コンウェイの法則への対処

コンウェイの法則を例にあげ、それらへの立ち向かい方の話に。

  • 細かいサービスを複数チームで取り扱うときにはジョブローテーションをすることなどで知識の共有化が有効
  • 1つのモノリシックなサービスに対して複数のチームが関わる場合は、設計方針などをWikiにまとめたり、勉強会形式で知識を共有するなどで対処している

また、組織とソフトウェア開発との関わり方の話になり…

  • 類似サービスをスクラッチで複数立ち上げてしまい、共有化できる部分の余地があったのにできない場合などもあり、そこは組織として働きかけないと難しい
  • 逆コンウェイのアプローチ（ドメイン分析に応じて組織を組成する）というやり方も方法としてはあるが、様々な事業を扱う会社においては現実的に難しい
  • アーキテクチャと組織はセットで考える必要がある

全体の感想

  • クリーンアーキテクチャの文脈から始まり、設計との付き合いかた、組織にどうやってなじませていくかなど、普段の技術トークでは聞きづらい面白い話がたくさん聞けた。特に理解して使っている実践者はマジで少ないので大変学びがあった。
  • 新しく生まれくるコードをどうやって保つかというところには皆さん苦心されているんだなと思いながらも、そこらへんを滞りなく動かす仕組みや組織づくりが肝要なんだなと改めて実感。
  • 浸透させる話題や、コンウェイの法則の話題などは自分も時々考えさせられる場面があるのですごいためになった
  • モデリングなどはユースケース駆動開発実践ガイド に書かれていた話と共通する部分があったで、ココらへんを素地にするといいのかなと思った
  • ゲーム文脈でクリーンアーキテクチャが流行っているっていうのは、もしかしてもんりぃさんとか話かな？と思った
  • 次回はちゃんと書籍を読んでディスカッション枠で参加したい
  • 今回速記された方（下の関連リンク参照）いるので細かいものはちょっとオミットしました。

全般的な参考リンク