問題タブ [ddd-repositories]

私はドメインモデルを持っています

• Customer- 集約ルート - 注文は顧客なしでは存在できないため
• Order- 実在物
• OrderStatus- 値オブジェクト

私のフォームでは、すべてのリストが必要OrderStatusesです。

すべての OrderStatuses のリストを含む空の注文エンティティを持つリポジトリから空の顧客エンティティ (AR) をフェッチする必要がありますか? これは厄介です。

エンジニアがガス井にアクセスするアプリケーションがあります。彼は、7 つの特性の任意の組み合わせを選択して、井戸のリストを表示できます。特性は、会社、州、郡、流域、支店、分野、事業者の順で表されます。アプリケーションが起動し、会社のリストを取得する必要があります。ユーザーに表示される会社は、セキュリティ資格情報に基づいています。リポジトリのベースとなる集約ルート/ドメイン オブジェクトは何でしょうか。私は最初にユーザーを考えましたが、ユーザーについて何も取得しませんでした。これらの項目とその他のいくつかの属性の組み合わせは、まとめて坑口情報と呼ばれます。それはリポジトリの集約ルートまたはドメイン オブジェクトでしょうか?

前もって感謝します

私はDDDを初めて使用します。トピックエンティティとレッスンエンティティがあります。トピックには多くのレッスンがあります。トピックとレッスンを追加/削除する必要があります。エンティティ用に2つの異なるリポジトリを作成する必要がありますか、それともすべてのレッスンを処理する1つのTopicRepositoryを作成する必要がありますか？これは古典的なOrder-OrderItemモデルですか？

ありがとう

同じエンティティに対して 2 つのインスタンスを作成しないように、どの集約ルートが既に作成されているかを追跡する責任をプロジェクト内のどのクラスが担当する必要がありますか。リポジトリは、作成したすべての集計のリストを保持する必要がありますか? はいの場合、どうすればいいですか？シングルトン リポジトリを使用する必要がありますか? 別のオプションは、この「キャッシング」を別のクラスにカプセル化することでしょうか? このクラスはどのように見え、どのパターンに適合しますか?

私はO/Rマッパーを使用していないので、それを処理する技術がそこにある場合、それを使用できるようにするために、それがどのように（どのパターンを使用するかなど）行うかを知る必要があります

ありがとう！

リポジトリを使用してデータベースと通信するシステムがあります。リモートサービスの正しい定義は？またはより良い、

[...] は外部 Web サービス用であるため、リポジトリはデータベース用です。

ServiceAgents について多くの場所で見つけましたが、これが正しい定義かどうかはわかりません。

私は新しいプロジェクトを始めたばかりで、自然に多くの新しい技術を使用することを選択しました.

(Fluent) NHibernate、ASP.NET MVC 3 を使用しており、リポジトリ パターンを適用しようとしています。

ビジネス ロジックを別のプロジェクトに分割し、レポジトリをラップするサービスを定義して、NHibernate プロキシの代わりに POCO を返し、フロント エンドと DA ロジックの間の分離をさらに維持できるようにすることにしました。これにより、後で API と同じロジックを簡単に提供できるようになります (要件)。

私は、すべて IEntity を実装する NHibernate マップ エンティティの 1 つであるジェネリックIRepository<T>インターフェイスを使用することを選択しました (私のインターフェイスは実際にはマーカーのみです)。T

問題は、これが集約ルート パターンに反することであり、私は貧血ドメイン モデルの痛みを感じ始めています。

別のものにぶら下がっているオブジェクトを変更すると

• ルート <- 変更
  • 子 <- 変更

私のサービスでは、次のことを行う必要があります。

最初に子を保存しないと、NHibernate から例外が発生します。私の汎用リポジトリ (現在、1 つのサービスで 5 つ必要です) は正しい方法ではないように感じます。

コードをより柔軟にするのではなく、より脆くしているように感じます。新しいテーブルを追加する場合、すべてのテストでコンストラクターを変更する必要があります (実装に DI を使用しているので、それほど悪くはありません) が、少し臭いようです。

この種のアーキテクチャを再構築する方法について誰かアドバイスはありますか?

リポジトリをより具体的にする必要がありますか? サービス抽象化レイヤーは行き過ぎですか?

編集：役立ついくつかの素晴らしい関連する質問があります：

• リポジトリ パターンのベスト プラクティス
• リポジトリ パターンのヘルプ
• 建築上の難問

テストユニットにNUnitを使用しています。ドメインにインターフェースがあるので、永続層にこれらのインターフェースを実装する準備ができています。私の質問は、これらのリポジトリをテストするための単体テストを実際にどのように行うのかということです。これは、データベースから直接テストするのは良い考えではないと思います。SQLiteを使用している人を聞いたことがありますが、代わりにモックを使用しても大丈夫ですか？実際のエンティティでモックを提供できるのに、なぜ人々はインメモリデータベースにSQLiteを使用しているのですか？

どんな例でも歓迎されます。

注：これは、マッピングとしてNHibernateとFluent NHibernateを使用するC＃でコーディングされたリポジトリーを対象としています。

ありがとう。

Domain-Driven Design: Tackling Complexity in the Heart of Software の次の定義に基づいて、

集約とは: データ変更の目的で 1 つの単位として扱われる、関連付けられたオブジェクトのクラスター。外部参照は、ルートとして指定された AGGREGATE の 1 つのメンバーに制限されます。AGGREGATE の境界内では、一連の整合性ルールが適用されます。

Aggregate ルートがリポジトリへの参照を保持する必要はないと思います。Aggregate ルートは、そのエンティティと集計への参照を保持する必要がある唯一のルートであるため、非公開にする必要があります。

私のリポジトリはどのようにしてこのプライベート データを保持し、復元できますか?

編集：

古典的な Order、OrderLines の例を見てみましょう。

オーダーは集約ルートです。

その線はエンティティです。

Aggregate ルート (注文) は、そのエンティティ (注文明細) への参照を保持できる唯一のオブジェクトであるため、リポジトリから注文明細を保持する方法がわかりません。

リポジトリ内の ID でオブジェクトをプルする一般的な方法を考え出そうとしています。私のデータベースでは、通常、すべての ID は主キーであり、整数型です。将来的にはそうではない場合もあるかもしれませんが、それでもすべてのオブジェクトに対して同じメソッドを維持したいと考えています。これが私のインターフェイスの外観です。

リフレクションを使用してオブジェクトのIDを取得し、その特定のオブジェクトのすべてのオブジェクトを解析するコードを見てきました(理想的ではありません)。私はまた、このようなものを見てきました:

私はここからそのアイデアを得ました。

私はまだ表現に慣れていないので、これがうまくいくかどうかわかりません。次の表現を含めることができるので、そうなると思います。

しかし、それは実際には GetById ではなく、任意の式を使用して必要なものを取得できると思いますよね?

どんな考えも高く評価されます。

アグリゲートごとに 1 つのリポジトリーを持つことをお勧めします。

ただし、同じ集計オブジェクトを 2 つの異種データ ストアから取得できる場合があります。背景の場合、そのオブジェクトは次のとおりです。

1. データ ストアAから取得(リモートおよび読み取り専用)
2. 検証のためにユーザーに提示される
3. 検証時、データ ストアBにインポート(ローカル & 読み取り/書き込み)
4. データ ストアBから取得して変更することができます。

明らかに (またはそうではない)、そのための一意の集約リポジトリを作成することはできません。ある時点で、オブジェクトがどのデータ ストアからフェッチされたかを知る必要があります。

ドメイン層がインフラストラクチャを無視する必要があることを考えると、私の特定のケースでは、リポジトリ パターンと一般的な DDD を適切に実装する方法についての私の理解が何らかの形で崩れます。

何か問題がありましたか？