DDD 7章 続き 172ページ。
集約は、オブジェクトの保管・取り出しの単位である。そのためのメカニズムとしてリポジトリ(REPOSITORY)パターンを検討する。
7章の例では、顧客、貨物、場所、運送イベント、輸送イベントの5つが候補。
ENTITY で、かつ集約のルートと決めたオブジェクトはすべてリポジトリ作成の候補。
リポジトリはドメイン層のオブジェクト。必要性・妥当性を検証するためにアプリケーション(ドメインの利用者)の視点で検討する。
顧客(Cuctomer)リポジトリ
予約アプリケーションで、顧客をリポジトリから探すことが必要。
探し方は、リポジトリクラスのメソッドで定義する。
find By Customer ID
find By name
find By Cargo Tracking ID
の三種類が役に立ちそう。
場所(Location)リポジトリ
予約アプリケーションで、貨物の送り先を指定するために場所を探すことが必要。
find By port code
find By city name
輸送(Carrier Movement)リポジトリ
配送活動記録アプリケーションでは、貨物を送るための輸送をリポジトリから探すことが必要。
find By Schedule ID
find By From To
貨物(Cargo)リポジトリ
配送活動記録アプリケーションで、貨物を指定する必要がある。
find By Cargo Tracking ID
find By Customer ID
運送イベント(Delivery Event)リポジトリ
関連を検討した時、配送履歴を運送イベントのコレクションで実装する方針にした。
この方針だと、運送イベントをリポジトリから取り出す操作はない。つまり、リポジトリは作成しない。
(後で方針を再検討するらしい)
---
なるほど。
問題領域でどんな検索が必要か、やりたいのかを、リポジトリとそのメソッドで定義するのか。
リポジトリと検索メソッドを検討すると、このソフトウェアで何を実現するかが具体的になる。
7章のモデリングのステップをまとめると、
1.アプリケーションクラスとドメインクラスを分離
2.(ドメイン層で)ENTITY と VALUE OBJECT を識別
3.関連とその方向を検討
4.集約の境界を検討
5.リポジトリと検索メソッドを検討
という5ステップ。
たしかに、4章のレイヤ・アーキテクチャ、5章の ENTITY, VALUE OBJECT、6章の AGGREGATE と REPOSITORY の具体例になっている。
モデリングの時に、具体的に検討すべき項目と選択肢、実践的な判断ルールが7章ではいろいろ出てきた。
モデルを検討する時、アプリケーションの視点、対象業務(問題領域)の視点を繰り返し使うことが印象的。
これがドメイン駆動の設計というわけですね。
配送の一般的なモデルではなく、国際配送、それも配送状況の追跡という問題領域にフォーカスする。
問題領域を深く検討すると、モデル作成の選択肢に、具体的な判断基準があることが理解できた。
モデルの違いが、コレクションの使い方とか、データベースアクセスとか、実装に影響することも理解できた。
集約は、オブジェクトの保管・取り出しの単位である。そのためのメカニズムとしてリポジトリ(REPOSITORY)パターンを検討する。
7章の例では、顧客、貨物、場所、運送イベント、輸送イベントの5つが候補。
ENTITY で、かつ集約のルートと決めたオブジェクトはすべてリポジトリ作成の候補。
リポジトリはドメイン層のオブジェクト。必要性・妥当性を検証するためにアプリケーション(ドメインの利用者)の視点で検討する。
顧客(Cuctomer)リポジトリ
予約アプリケーションで、顧客をリポジトリから探すことが必要。
探し方は、リポジトリクラスのメソッドで定義する。
find By Customer ID
find By name
find By Cargo Tracking ID
の三種類が役に立ちそう。
場所(Location)リポジトリ
予約アプリケーションで、貨物の送り先を指定するために場所を探すことが必要。
find By port code
find By city name
輸送(Carrier Movement)リポジトリ
配送活動記録アプリケーションでは、貨物を送るための輸送をリポジトリから探すことが必要。
find By Schedule ID
find By From To
貨物(Cargo)リポジトリ
配送活動記録アプリケーションで、貨物を指定する必要がある。
find By Cargo Tracking ID
find By Customer ID
運送イベント(Delivery Event)リポジトリ
関連を検討した時、配送履歴を運送イベントのコレクションで実装する方針にした。
この方針だと、運送イベントをリポジトリから取り出す操作はない。つまり、リポジトリは作成しない。
(後で方針を再検討するらしい)
---
なるほど。
問題領域でどんな検索が必要か、やりたいのかを、リポジトリとそのメソッドで定義するのか。
リポジトリと検索メソッドを検討すると、このソフトウェアで何を実現するかが具体的になる。
7章のモデリングのステップをまとめると、
1.アプリケーションクラスとドメインクラスを分離
2.(ドメイン層で)ENTITY と VALUE OBJECT を識別
3.関連とその方向を検討
4.集約の境界を検討
5.リポジトリと検索メソッドを検討
という5ステップ。
たしかに、4章のレイヤ・アーキテクチャ、5章の ENTITY, VALUE OBJECT、6章の AGGREGATE と REPOSITORY の具体例になっている。
モデリングの時に、具体的に検討すべき項目と選択肢、実践的な判断ルールが7章ではいろいろ出てきた。
モデルを検討する時、アプリケーションの視点、対象業務(問題領域)の視点を繰り返し使うことが印象的。
これがドメイン駆動の設計というわけですね。
配送の一般的なモデルではなく、国際配送、それも配送状況の追跡という問題領域にフォーカスする。
問題領域を深く検討すると、モデル作成の選択肢に、具体的な判断基準があることが理解できた。
モデルの違いが、コレクションの使い方とか、データベースアクセスとか、実装に影響することも理解できた。