いよいよ最終章。
戦略をまとめ上げる
14章・・・モデルの整合性を維持する（コンテキストマップ/境界づけられたコンテキスト)
15章・・・蒸留(コアドメイン)
16章・・・大規模な構造(進化する秩序)
これらは、組み合わせて作用させることができる。
書籍では、実際の図が見れるのでとても参考になる。
境界づけられたコンテキスト+責務のレイヤ、責務のレイヤ+コアドメイン・汎用サブドメインなど、この図が書ければ確かに大規模なアプリケーションも整理できる。
どうするのか
- コンテキストマップを書く
- ユビキタス言語に注意を払う
- コアドメインを識別する。ドメインビジョン文書を書く
完璧な答えを求めない。継続的に改良して、新たに学んだことを反映すること。
誰がするのか
自己規律型のチームがそれを行う。開発チームが行うこと。
開発チームより権力がある人が書いてもうまくいかない。
6つの注意点
- 意思決定はチーム全体に伝える
- 意思決定プロセスはフィードバックを吸収する
- 計画は進化を許容する
- アーキテクチャチームに最も優秀な人物を持ってはいけない
- 戦略的設計にはミニマリズムと謙虚さが必要
- オブジェクトはスペシャリスト、開発者はジェネラリスト
なかなか、４がわかりづらいかもしれません。
アーキチームに優秀な人物を当てて、技術的に最も未熟な開発者だけを実際のアプリケーション構築に残してはいけないということ。アプリケーションの構築には設計スキルが必要だからですね。
ここまで、何度も言われてきたことです。