TL;DR
- 共有されたモデルはコードにも反映する必要があり、型システムを使うとソースコードをドキュメントとして機能させられる。
- ドメインモデルは、単純な値、AND と OR による複雑なデータ、ワークフローという典型的なパターンで組み立てる。
内容
コードをドキュメントにする
共有されたモデルの重要性で見たように、共有されたモデルはコードにも反映される必要がある。理想は、ソースコードがそのままドキュメントとして機能することである。そうすれば、ドメインエキスパートやほかの非エンジニアも、コードをレビューしたり設計に加わったりできる。型システムを使うと、これを実現できる。型で書いたモデルは、第2章で作ったドメインの文書とほとんど同じ形になる。
ドメインモデルの典型的なパターン
ドメインモデルには、典型的なパターンがある。
1 つ目は単純な値である（単純な値のモデリング）。文字列や整数などのプリミティブ型で表される基本的な構成要素だが、int や string ではなく、OrderId や ProductCode のようなユビキタス言語の概念として考える。
2 つ目は複雑なデータである（複雑なデータのモデリング）。AND による値の組み合わせは、密接に関連したデータのまとまりを表す。紙の世界でいえば、書類そのものや、名前、住所、注文のような書類の中のひとまとまりの要素にあたる。OR による選択肢は、Order（注文）または Quote（見積もり）、UnitQuantity（個数）または KilogramQuantity（キログラム数）のような選択を表す。
3 つ目はワークフローである（関数によるワークフローのモデリング）。入力と出力を持つビジネスプロセスを表す。
エンティティ、値オブジェクト、集約
ドメイン駆動設計では、ID のような永続的なアイデンティティを持つオブジェクトをエンティティ、持たないオブジェクトを値オブジェクトと呼ぶ（値オブジェクト、エンティティ）。
エンティティの中には、ほかのエンティティのコレクションを持つトップレベルのエンティティもある。ドメイン駆動設計では、このようなエンティティのまとまりを集約、トップレベルのエンティティを集約ルートと呼ぶ（集約）。
キーワード
自分の理解
そもそも、ドメインの文書化で作る文書が日本語話者にはハードルが高いので、なおさらである。ドメインに日本語を使うを試してみたい。