エリックエバンスのドメイン駆動設計の「第6章ドメインオブジェクトのライフサイクル」まとめ

今回は、「第6章ドメインオブジェクトのライフサイクル」のまとめです。

永続化を伴うようなライフサイクルの寿命が長いドメインオブジェクトを管理することは、以下のような課題を解決する必要があるので、難しくなります。

ドメイン駆動設計では、３つのパターン（集約、ファクトリ、リポジトリ）を通して、これらの課題に対応しています。

課題1.で説明されている不変条件とは、 何かの業務を行う時は維持すべき重要なビジネルルールが常に守られていること。です。

まずは、業務視点で守るべきビジネスルールを明確化した上で、システムとしての対応は

ということになります。

※具体的な例は、集約のところで説明します。

複雑なドメインモデルにおいて、ライフサイクルの遷移に伴う一貫性を保証することは難しい状況になりえます。

その状況化で、重要なビジネスルールが守られることを保証するために、ドメインとして境界を定義して、境界内で重要なビジネスルールが守られることを保証します。

その境界の一つ一つが集約という単位になります。

DDD本で説明されていた例になりますが、『ダメな集約例』と『イケテル集約例』です。

f:id:mmm-mao:20150526083819j:plain f:id:mmm-mao:20150526083816j:plain

『ダメな集約例』のどこがダメかというと、以下の流れで注文明細が操作されたケースです。集約の単位が購入注文明細になっているので、フェーズ２の同タイミングで操作された場合に、ビジネルルール（承認限度額>=注文明細の総額）が破られてしまいます。

f:id:mmm-mao:20150526084826j:plain

そのため、今回のビジネルルールを守るためには、購入注文と購入注文明細を１つの集約として捉える必要があります。

集約の生成に関しては、以下の課題があります。

これらの課題を解決するためにファクトリという考え方を用います。

ライフサイクルの初期以降後に、何かの業務イベントを実行するためには、既に存在するドメインオブジェクトが必要になります。また、実行後は、ドメインオブジェクトを永続化する必要があります。

ドメイン駆動設計の目標は、技術ではなく、ドメインに焦点を合わせることなので、上のような具体的な手段をカプセル化するために、リポジトリという考え方を用います。

ドメインの設計から永続化技術などを分離するために、ドメイン層としてはリポジトリのインターフェースだけを提供して、インフラストラクチャで具体的な技術手段を用いた操作を提供する。という責務にしています。

また、永続化する部分に関しても、よくsaveメソッドだけ提供されている例を見かけますが、僕が普段開発する場合は、ユビキタス言語に関するシンプルな操作（登録や退会）を提供しています。

f:id:mmm-mao:20150526081842j:plain

集約を区切るスコープによって、不変条件の維持すべき範囲が示され、ライフサイクルの遷移における複雑さはファクトリとリポジトリによってカプセル化されます。

以上が「第6章ドメインオブジェクトのライフサイクル」のまとめです。