2

DDD を使用する場合にリポジトリを使用する利点は、オブジェクトがどのように永続化されるかを気にせずにドメイン モデルを設計できることです。また、リポジトリのさまざまな実装を簡単にスワップインおよびスワップアウトできるため、最終製品をより柔軟にすることもできます。そのため、リポジトリの実装は、SQL データベース、REST Web サービス、XML ファイル、またはデータを保存および取得するその他の方法に基づくことができます。モデルの観点からは、集計ルート オブジェクトの格納と取得に使用できるこれらの魔法のコレクションだけが存在することが期待されます。

2 つの通常のメモリ内コレクション、たとえば anIList<Order>と anがあるIList<Customer>場合、一方のコレクションを変更すると他方のコレクションが影響を受けるとは思いません。では、同じロジックをリポジトリに適用する必要がありますか? リポジトリの実際の実装は、実際には同じデータベースにアクセスする場合でも、互いに完全に分離する必要がありますか?

たとえば、顧客が削除されたときに対応する注文が削除されるように、Customersテーブルとテーブルの間にカスケード オン デリートの関係を SQL データベースで設定することができます。Ordersただし、後でSQLCustomerRepositoryが に置き換えられると、この機能は壊れRESTCustomerRepositoryます。

リポジトリが互いに完全に分離されており、それに応じてリポジトリの実際の実装も分離されている必要があるという仮定の下にモデルを常に配置する必要があると考えるのは正しいですか?

では、データベースに依存するのではなく、ドメイン モデルでこれを明示的に定義する必要がありますかOrders? 現在のとにアクセスCustomerするメソッドを使用して言います。CustomerService.DeleteCustomer()ICustomerRepositoryIOrderRepository

リレーショナルの世界から抜け出して DDD の世界に足を踏み入れるのに苦労しているだけだと思います。私は、テーブルと PK/FK の関係の観点から物事を考えたいと思っていますが、データベースが関係していることはまったく無視する必要があります。

4

4 に答える 4

1

あなたが見逃しているのは、集約ルートがコンテキスト境界を描画することだと思います。
簡単に言えば、下にあるものは、集約ルート自体と一緒にのみ意味があります。

私が見ているように-注文は集約ルートではなく、顧客集約ルートコンテキストに存在するエンティティです。つまり、リポジトリは集約ルートごとにあるはずなので、Order リポジトリは必要ありません。したがって、Customer.Orders も永続化する方法を知っているはずの CustomerRepository のみが存在する必要があります。

私自身はそれほど心配せず、リポジトリ パターンを完全に省略し、NHibernate ORM に頼っています。状態の変化を正しく追跡および監視するリッチ ドメイン モデルは、実際に update/select sql ステートメントを送信する方法よりもはるかに重要です。

また、ものを削除する前によく考えてください。

于 2011-06-14T10:30:09.350 に答える
0

ドメイン モデルは、ドメインのトランザクション操作をモデル化する必要があります。Customer エンティティで Customer に Orders を配置することにより、Customer が削除されたときに、彼の Orders も削除されるべきであると言っています。

Customer に OrderIds がある場合、それは異なります。顧客と注文の間に関連付けがあるよりも。この場合、Customers の OrderIds のリストに追加または削除することで、注文を追加または削除するのではなく、関連付けを追加または削除していると言っています。

リポジトリの実際の実装は、実際には同じデータベースにアクセスする場合でも、互いに完全に分離する必要がありますか?

はい、ほとんどの場合。Order と Customer Aggregate ルートの両方を作成することにした場合、それらは互いに独立しており、独立して同時に変更できるようにする必要があると言っています。つまり、変更が 2 つの間でトランザクション可能である必要はありません。Customer のみを集約ルートにし、Orders のリストを持たせる場合、Customer エンティティが Orders に何が起こるかを指示し、Customer を変更すると変更がその Orders にカスケードされると言っています。

あなたの例では、集計ルートとして Customers があるようです。そして集約ルートとして注文します。それぞれに独自のレポがあります。顧客は、1 対多の関連付けをモデル化するための OrderIds のリストを持っています。顧客を削除した場合、顧客削除イベントを発行して、この顧客に関連するすべてのものをクリーンアップすることができます。

于 2014-06-17T04:56:42.583 に答える
0

エンティティごとではなく、集約ルートごとにリポジトリがあるため、集約ルートの子のカスケード削除でも、集約ルート リポジトリは分離されているため適用できます。

削除をカスケードしたり、他の集計ルートに副作用を与えたりしないでください。アプリケーション層でこのロジックを調整してください。

于 2011-10-25T08:47:44.050 に答える
0

顧客を削除しないでください。顧客は削除されず、非アクティブにされます。また、削除注文をカスケードしないでください。奇妙な場所に移動します。注文は、処理されたときに常に保持する必要があります。アプリケーションのレポートを考えてみましょう。カスケード削除を選択したため、110 万の収益がなくなったとします。

于 2011-10-25T07:30:26.687 に答える