ドメイン駆動設計をざっくり把握したい②

前回の続き。
DDDの戦術的設計をざっくりまとめる。

戦術的設計

アーキテクチャパターンの一つで、下位層から順番にインフラストラクチャ層、ドメイン層、アプリケーション層、UI層に分離される。
原則として下位層にしか依存してはいけない。

「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも抽象に依存すべきである。
抽象は、実装の詳細に依存すべきではない。実装の詳細が、抽象に依存すべきである。」

インフラストラクチャ層のコンポーネントは、ドメイン層が定義するインターフェースに依存するべきである。
具体的には、インターフェースIRepositoryをドメイン層に実装し、具象暮らすRepositoryをインフラストラクチャ層に実装する。

一意なモノを表現する概念のことで、実装時は一意に特定するポイントとなる属性や振る舞いだけに注目することが重要。
ビジネスロジックを内包した一般的なクラス群の呼称、getterとsetterしかないドメインモデル貧血症というアンチパターンに注意する。

とあるドメインにおいてのサービスは、そのドメインに特化したタスクをこなす、ステートレスな操作のこと。

集約とは、エンティティのまとまりを表し、整合性を保ちながらデータを更新する単位のこと。
責務は、エンティティ群の生成/読み込み/変更/保存等のライフサイクル管理。

ファクトリとは、集約を生成する責務をもつ概念のこと。
特定の集約にて、別のエンティティ(集約も含む)を生成することが多い。

リポジトリとは、エンティティから構成される集約の保存と取得の責務をもつ概念のこと。
依存関係逆転の原則の説明にあるように、リポジトリのインターフェースは、集約と同じドメイン層のパッケージに配置。
リポジトリの具象クラスはインフラストラクチャ層に配置する。

ここでいうアプリケーションとは、
ドメインモデル、ユーザーインターフェース、アプリケーションサービス、インフラストラクチャのコンポーネント全体を指す。

JavaのSpringや.NETのASP.NETなどのWAFがこの層に属する。
ドメインモデルのユーザーインターフェースへのレンダリングは、DTOを用いることが多い(当然他の方法もある)。
アプリケーションサービスが集約インスタンスを取得し、それをDTOにレンダリングする。
ドメインモデルに依存するかどうかはケースバイケース。

アプリケーションサービスとは、ドメインモデルの調整を行う責務をもつコンポーネント。
ユーザーインターフェースとドメインモデルの橋渡し役となるので、それぞれの層の依存関係を調整するのが大切。

インフラストラクチャは、アプリケーション全体の技術的機能を提供する責務をもつ。
DIPをい、アプリケーション内のあらゆるクライアントは抽象に依存するようにし疎結合化を図る。