エリック・エヴァンスのドメイン駆動設計を読んで

全体の感想

理解の難易度が高めで分量が多い。

難しい理由の一つはコードを交えた具体例がほぼ無い事かと思われる。実践ドメイン本やDDDやってみた系のリポジトリを参考にしつつ読むと良いかもしれない。

継続的なリファクタリングやドメインエキスパートとのコミュニケーションでコアとなるドメインモデルを改善する事が最も重要だという事が繰り返し述べられている。

幾つかの定義された語句はDDD本を読んだ人の中で一般教養的に使える可能性が高く DDDで言う所のXXXみたいな感じで通じると思われるので抑えておいて損は無いはず。

エッセンス抜粋

幾つか語句説明やエッセンスを抜き出して雰囲気を伝える*1

・ユビキタス言語
開発者とドメインエキスパートが同じ意味の用語を設定し利用し齟齬を防ぐ

・モデル駆動設計
モデリングと実装を完全に作業分担すべきでない
コードを通してモデルを表現する必要が有る

・エンティティと値オブジェクト
エンティティは識別可能でユニークなもの（特定のユーザー等）
値オブジェクトは不変で変更管理を必要としないもの（性別とか日付等）
値オブジェクトは可変にするより別の値オブジェクトを作成する方がシンプルに実装可能
ただし大量の値オブジェクトを生成する時はリソースに注意

・サービス
引数と結果がドメインオブジェクト
ドメインモデルのインターフェイスを持つ
それ自体は状態を持たない
アプリケーション層でドメインモデルが相互動作する

・集約、ルートエンティティ
境界内の他エンティティを参照し境界内の不変条件をチェックする責務を持つ

・リポジトリ
データベースとのやりとり等 情報の永続化
トランザクションはクライアントで実施
インスタンス生成はファクトリに委譲しリポジトリと組み合わせない方が良い

・コアドメイン
ビジネスの本質、長期的なリソースを集中すべき

・汎用サブドメイン
汎用的なモデル、実装に事前知識が要らない、短期的リソースを割当てる事も可能

・大規模な構造
フレームワーク的なもの。
レイヤ化は成功しやすい手法（実装上のデザインパターンではなくドメインモデル上のレイヤ分けが紹介されていた）

・アーキテクチャの作り方
複数のアプリケーションチームが共同で作るパターン
アーキテクトチームが先導するパターン（ただしアプリケーションチームの実装を妨げない事が重要）