この書籍を読みました
DDDとは
・ソフトウェアアーキテクチャの一種でドメインとは「ソフトウェアで問題解決しようとする対象領域」のこと。
・ドメインモデル（モデル）は問題解決のためにどんな要素が必要か選択することで作られる。
・いいモデルを作るためにはドメインエキスパートと話すこと、運用で得られた発見をモデルに還元することが重要。
・ドメインをモデルに、モデルをソフトウェアに反映させることが重要。
・ユビキタス言語を英語で指定することで、そのまま関数名などに反映させられる
・モデルとソフトウェアを近づけるためにオブジェクト志向が使われることが多い
・モデル表現を分離するため、クリーンアーキテクチャ等の様々なアーキテクチャが存在する
DDDでの実装に取り組む上で重要な考え方
・課題発見が何よりも大事
・小さく初め、小さく失敗
DDDのモデリング
・ユースケース図
・ドメインモデル図（ユースケース図から対象のドメインを定義したものをルールに沿って記載）
DDDの実装
・ドメイン知識をユースケース層ではなく、ドメイン層で表現する。例えばタスク管理アプリのコードを書く時、タスクの初期状態が未完了であることをユースケース層で表現するのではなく、ドメイン層で表現する。これによってTaskクラスを見るだけでドメインを理解することができる
・インスタンスはコンストラクタから生成されるようにすることで制約がつき、整合性が保証される
・ミューテーションメソッドを用いることでもインスタンスに制約をかけることができる
実装は以下のように少しずつ改善していけばいい
テスト実装 → 動くコード → リファクタリング → DDDを意識した実装
DDD固有のモデリング手法
・集約：強い整合性をもったオブジェクトの固まり
・集約のオブジェクトの取得は一つのトランザクションで行う
・ドメインモデル、ユビキタス言語の想定範囲を決める必要がある、この範囲を境界づけられたコンテキストと呼ぶ
設計の原則
高凝集、低結合が設計の基本原則
凝集度・結合度はモジュール（機能をひとまとまりで捉えた単位）ごとに考える
アーキテクチャ
3層アーキテクチャ
このアーキテクチャの弱点は
・ビジネスロジック層が低凝集になりがちなこと
・低凝集、高結合になりやすい
この理由は仕様をユースケース層、ドメイン層に分けず、ビジネスロジック層だけで表現しようとすることで責務過剰となるから。また、ドメイン知識をモデルに表現する可能性があり、そうなるとビジネスロジック層、データアクセス層にドメイン知識が分散してしまうから。
レイヤードアーキテクチャ
三層アーキテクチャの弱点を消したアーキテクチャだが、以前としてドメイン層がインフラ層に依存し、高結合となる。
オニオンアーキテクチャ
依存関係逆転の原則とは
画面からDBに保存する処理を呼び出す時、画面はDBに保存する処理に依存する。そのため、この２つの処理が抽象を参照するようにすることで依存関係の問題を解決する。また、詳細の処理内容に関しても抽象に依存させることで上の問題を解決する。
依存関係逆転の法則を利用し、インフラ層がドメイン層に依存する形にしている。インターフェースをドメイン層に、実装クラスをインフラ層に定義する。ドメイン層が外界から独立する形となる。
クリーンアーキテクチャ
エンティティをドメイン知識の中心とし、ユースケース層等ヘキサゴナルアーキテクチャを受け継いだアーキテクチャとなっている
ドメイン層の実装
ドメイン知識をドメイン層に記載する。新たなエンティティの生成にはファクトリーメソッド（new関数）等を使用し、不整合な値が生成されないことを保証するような実装とする。また、そのドメインの振る舞いとなるようなメソッドもドメイン層に記載する。ドメインサービスとして表現するか、ユースケース層に記述するか迷うような処理を実装しなければならない場面に遭遇することがあるかと思うが、判断基準として「それがビジネスルールであるか」、「それとも何をするか（what）を表現しているか」という基準で考えるといい。