リポジトリが構築中に互いに通信する場合、ドメイン駆動の設計原則に違反しますか?
ユーザーアドレスリポジトリが都市/地域/国のリポジトリと通信してデータを取得する例?
リポジトリが構築中に互いに通信する場合、ドメイン駆動の設計原則に違反しますか?
ユーザーアドレスリポジトリが都市/地域/国のリポジトリと通信してデータを取得する例?
ドメイン駆動設計に違反しています。リポジトリは相互に参照すべきではないと思います。また、リポジトリとデータベース テーブル間で 1 : 1 をマッピングしないでください。
Aggregate
これがとの概念ですAggregateRoot
。例として、データベースに 2 つのテーブルがあるとします。
Order
OrderLine
1:n の関係では、(Order, OrderLine) は集約として定義されます。これは、OrderLine が Order なしでは単独で存在できないためです。この場合、Order はこの集計のルートです。
これにより、2 つのリポジトリを作成する代わりに:
OrderRepository
OrderLineRepository
OrderRepository
カスケードロード、挿入、および削除を使用して、集約全体を処理するのは1 つだけにする必要があります。OrderLine
したがって、あなたの場合、住所/都市/地域/国のリポジトリが存在するかどうかを考慮する必要があります。
この助けを願っています
あなたの問題にはいくつかのアプローチがあります:
2 つの骨材の根の間の密接な関係を維持し、最初の根を水和するときに 2 番目の根の全体の骨材を体系的に水和します。これには、最初のリポジトリが 2 番目のリポジトリと通信する必要があります。これは、IMO によって DDD の原則が破られることはありませんが、パフォーマンスに関して問題が生じる可能性があります。
2本の根をゆるく結びます。これは基本的に、完全なインスタンスではなく、参照されたルートの ID を指すことを意味します。クライアント コードまたはルート自体 (後者は悪い習慣だと言う人もいます) は、リポジトリを呼び出して、参照されたルートをその ID から復元します。
City、Region、Country などのオブジェクトは実際には (不変の) 値オブジェクトであり、ID を必要とせず、それ以上の影響なしに任意の集約ルートまたはエンティティから直接参照できることを認識してください。これは、これらのオブジェクトのリポジトリがないことも意味します。
オプション 1 と 2 のどちらを選択するかは、単に技術的な問題であり、パフォーマンスと開発者の快適さにのみ影響します。オプション 3 は、ビジネスに影響を与える可能性のあるドメインの選択です。都市、地域、および国は、ユーザーが作成、変更、および削除できる大きなドメイン エンティティですか? それら専用の特別な画面はありますか? これらは、決定を下す前にドメインの専門家と話し合う必要がある問題です。
役立つリンク:
http://tech.groups.yahoo.com/group/domaindrivendesign/message/8696
システム内の ISO 通貨と ISO 国で同じ問題が発生しました。サブエンティティとして必要な通貨および/または国のエンティティを持っていた (および対応するリポジトリを持っている) ほぼすべての集約ルートが見つかりました。これは、データ管理とデータ取得の観点から非効率的であることが判明したため、次のことを行いました。
私の経験からすると、DDD とブルーブックは非常に貴重なガイドですが、100% 正確に採用する必要はありません。
お役に立てれば ...
良い。DDD のリポジトリの全体的な目的は、データ ソースを抽象化することです。ユーザーアドレスが都市/地域/国を完全にする必要がある場合は、それらのリポジトリを使用してください。
このアプローチの問題は、クエリがかなり非効率になることです。
代わりに、必要なすべての情報を含むユーザー アドレスをロードするビューをデータベースに作成します (または、ORM がある場合はそれを使用します)。
要約する:
DDD には、リポジトリの実装方法を指示するものは何もありません。DDD は、情報がデータ ソースにどのように格納されていても、リポジトリから読み込まれたエンティティが完全でなければならないことを非常に明確にしています =リポジトリは抽象化レイヤーとして定義されているだけです