エリック・エヴァンスのドメイン駆動設計 読書メモ6
読書メモ5 の続き。
第16章 大規模な構造
1モジュールが適切なサイズに切り出されていても、モジュール数が多くなると複雑さにより理解が難しくなる。このときシステム全体の大まかな構造(大規模な構造)が助けになる。
ある例では、モジュールが属するレイヤを明らかにし、違反しないようにすることで全体的な構造の理解が促進された。
進化する秩序
構造は設計に制約を課す。
制約が無いとシステムの全体像が理解しづらくなるが、事前に制約を課すと設計や開発に無理が出る。
大規模な構造はアプリケーションと共に進化させる。設計やモデルの詳細な意思決定を構造が制約しすぎないように気をつける。
構造は理解不能なほどモジュールが多いとき以外は必要ではない。うまく当てはまる構造が見つからないなら無い方がましだ。
システムのメタファ
システムを表すメタファとして、メンバの想像力を捉え役立つ方向に導きそうなら、メタファを構造とするのが良い。
メタファは不正確なので構造として不適切になっていないかは適宜調べる。不適切なら取り除く。
責務のレイヤ
責務に基づくレイヤを設定することで構造を作る。
緩やかなレイヤシステム（直下以外の下位層へのアクセスを認める）が責務のレイヤに最適だ。
着脱可能コンポーネントのフレームワーク
複数のアプリケーションが独立に設計されている場合は、複数の境界づけられたコンテキスト間の変換のため、統合がしづらくなる。
抽象化されたコアを蒸留し、特定のインタフェースの実装を自由に置換できるフレームワークを作ること。
抽象化されたコアのインタフェースを経由する限り、あらゆるアプリケーションがコンポーネントを使用できるようにすること。
いろいろな出自をもつモジュールを統合のためにコンポーネントにカプセル化するさいに便利な構造である。
ふさわしい構造へのリファクタリング
役に立つ構造はドメインに対する深い理解から生まれる。深い理解はイテレーション型開発プロセスにより達成される。
プロジェクトを通じて、大規模な構造を恐れずに再考しなければならない。プロジェクト初期の構造は深い理解に基づかないため、役に立たないことが多い。
だんだんと良い構造を見つけるためのコストを抑えて最大の効果を得るには:
- ミニマリズムに徹すること
- もっとも深刻な問題にのみ取り組む
- 構造の語彙をユビキタス言語に取り入れ、チームが自律的に構造を守る
- 構造の変更を経ることにより再構成が容易なシステムができる
- 継続的蒸留により、構造変更の難しさが軽減される。
第17章 戦略をまとめ上げる
戦略的設計の3つの基本原則: コンテキスト(コンテキストマップ)、蒸留、大規模な構造は相互に作用する。
大規模な構造と境界づけられたコンテキスト
大規模な構造は、入り組んだ単一のコンテキスト内でも役に立つし、複数のコンテキストを区分けする際にも役に立つ。
レイヤーをまたがるレガシーコンテキストがあるかもしれないが、レガシーシステムに関する主要な側面を捉えたことになる。
コンテキスト内のレイヤが他のコンテキストにも適用できる場合もある。
大規模な構造と蒸留
大規模な構造により、コアドメイン内の関係性、汎用サブドメイン間の関係が説明しやすくなる。
大規模な構造自体がコアドメインの重要部分になることもある。
まずは現状把握
- コンテキストマップを描く。一貫しているか？曖昧なところがあるか？
- 言葉の使われ方に注意する。ユビキタス言語は存在する？ユビキタス言語は豊かか？
- 重要なものは何か？コアドメインは識別されているか？ドメインビジョン宣言文はあるか？書けるか？
- 使っている技術がモデル駆動設計に向いているか？
- メンバが技術的スキルを持っているか？
- メンバはドメインを熟知しているか？関心を持っているか？
開発チームより権力をもつチームがアーキテクチャを作成することが多いが、たいていうまくいかない。
チーム数が少なく、チーム間で積極的な協調関係があり、設計能力が近く、単一の構造が各チームの欲求を満たせるような場合には、チームの代表者が議論された設計をチーム独自の判断で取り入れていく方法がうまくいく。
アプリケーションチームの同僚として動きながら、中央集権的に意思決定するアーキテクチャチームを構成した場合、意思決定に際して欠かせない6つのことがある。
- 意思決定をチーム全体に伝える
- 公式の権威を用いてルールの適用を強制する
- 開発からのフィードバックを十分に受けたものであれば無視されたり抜け道を作られたりすることが少ない
- 意思決定はフィードバックを吸収しなければならない
- 大規模な構造を作ったり蒸留したりするには、プロジェクト要求とドメイン知識を深く持つ必要がある
- プロジェクト要求とドメイン知識を深く持つのは開発チームである
- 開発チームからのフィードバックなしには戦略的設計できない
- 計画は進化を許容しなければならない
- アーキテクチャチームが最も優秀な人材をすべて吸い上げてはならない
- 開発チームに強力な設計者が必要だ
- 逆にアーキテクチャチームにドメインに詳しい人が必要だ
- スキルのある設計者を多く雇うという解法があり得る
- アーキテクチャチームを非常勤にするという解法がありえる
- 戦略的設計にはミニマリズムと謙虚さが必要である
- アーキテクチャチームはアプリケーションチームに制約を課しているという意識を持ち、自制しよう
- 戦略的設計とより小さい単位での設計は同じ人がやってよい
- 技術的フレームワークにもミニマリズムと謙虚さが必要だ
- 戦略的設計と同理由
- フレームワークは素人にはわからないこともある
- 素人にもわかることにこだわると使いにくいものができる
マスタプランに注意
全体的な秩序を事前に定めるマスタプランは、自然発生的な変化に適合できない。
参加者（ソフトウェア開発においては開発者）の意図が反映されないマスタプランは遠ざけられ、機能しない。
共同体のメンバ全員が適用できる原理の集合をAlexanderは提唱した。メンバは原理を状況に適合させ、有機的秩序を生み出す。
エピローグ
著者が関わったプロジェクトについての事後経過が書かれている。
感想
戦略的設計の最後のひとつ、大規模な構造について。コンテキストとは直交する分類を行うことで、頭の中を整理しやすくすること。なんらかの制約を課すことになるため、整理できていないと感じるまでは不要だろう。制約が不自然にならないように継続的に見直していくことも大事。大規模な構造の変化を繰り返すことで変化に強い設計になるという話があった。大規模な構造が継続的に変化する環境を個人的に経験していないので、これについては実感はわかない。
本が厚いので重厚な設計を説いているのかと最初は思っていたが、そうではなかった。コンテキストマップ、蒸留、大規模な構造のいずれにも継続的進化、事前に決めすぎないというアジャイルの文脈が息づいている。モデルレベルにおいても、戦略レベルにおいても、小さく継続的な設計が説かれている。
参加者に関わらせることによって活きた設計が出来るという精神は大事にしていきたい。開発者からみたときに第三者の押し付けがましい設計は（おそらく）機能しないってこと。
本を通じては広範な領域にわたる話があった。正直なところ私のあたまには入り切らない。折に触れて読み返したいと思う。