問題タブ [ddd-repositories]

DDDのことは初めてです。PROFILE クラスと PROFILE REPOSITORY CLASS があります。PROFILE クラスには次のフィールドが含まれます -> Id、Description、ImageFilePath

したがって、新しいプロファイルを追加すると、画像がサーバーにアップロードされ、そのパスがデータベースに保存されます。

プロファイルを削除すると、ファイル システムからもイメージが削除されます。

私の質問：

このためのロジックをどこに追加しますか。私のプロファイル リポジトリには Delete メソッドがあります。ここにこのロジックを追加する必要がありますか。または、両方のアクションをカプセル化するサービスを追加する必要があります。

コメントをいただければ幸いです...

ありがとう

Eric Evansのドメイン駆動設計を読んだ後、いくつか質問があります。私は検索しましたが、満足のいく答えを見つけることができた場所はありませんでした。以下の質問を明確に理解している方がいらっしゃいましたら、お知らせください。

私の懸念は

1. リポジトリは、DB、Webサービスから既存の集計を取得するためのものです。はいの場合、CanRepositoryはこのエンティティに対してトランザクション呼び出しも行うことができます（つまり、金額の転送、アカウントの詳細の送信など）

2. エンティティは、電子メール..ログなどを送信するためのインフラストラクチャレイヤーサービスを呼び出すビジネスロジックを持つメソッドを持つことができます（ISサービスを直接呼び出すエンティティメソッド）。

3. リポジトリの実装とファクトリクラスはインフラストラクチャ層に存在します。その正しいステートメントですか？

4. UIレイヤー（コントローラー）はリポジトリメソッドを直接呼び出すことができますか？または、これらをアプリケーション層から呼び出す必要がありますか？

私の心にはまだ多くの混乱があります...私を導いてください...私が使用している本EricEvanのドメイン駆動設計.......NETドメイン駆動設計とC＃

NHibernate、Fluent NHibernate、および Spring を理解しようとしています。

ドメイン駆動型の設計原則に従い、以下で構成される標準的な階層型 Web アプリケーションを作成しています。

• プレゼンテーション層 (ASP.Net)
• 以下を含むビジネス層:
  • アプリケーション層 (基本的には UI 層に表示される一連のメソッド)
  • リポジトリ インターフェイスとドメイン コンポーネント (アプリケーション層で使用)
• 永続層 (基本的に、ビジネス層で定義されたリポジトリ インターフェイスの実装)

ビジネス層への単一のリクエストの有効期間にわたって複数のリポジトリで共有できるように、NHibernate ISession をインスタンス化する方法を決定する手助けをしたいと思います。具体的には、次のことを希望します。

• ISession インスタンスと任意のトランザクションをリポジトリの実装を使用して制御できるようにします (おそらく、IOC フレームワークのいくつかの側面、インターセプターによるものでしょうか?)

• テストに適した方法で ISession インスタンスをリポジトリで使用できるようにします (おそらく、インジェクションまたは共有の「コンテキスト」抽象化を介して)

• 不要なトランザクションが作成されないようにします (つまり、読み取り専用操作のみが実行された場合)。

• SQLLite を使用するテストを記述できるようにする

• Fluent NHibernate の使用を許可してください

• リポジトリの実装がホスト環境を認識しないままにできるようにします。ビジネス層がプレゼンテーション層とインプロセスで実行されるのか、WCF の下 (IIS 内) で個別にホストされるのかはまだわかりません。 ）。

この問題を解決するための最初の試みは、レジストリ パターンを使用することでした。ISession インスタンスを ThreadStatic プロパティに格納します。ただし、その後の読書は、それが最善の解決策ではないことを示唆しています (ASP.Net はページのライフサイクル内でスレッドを切り替えることができるため)。

あらゆる考え、部品の解決策、パターン名、最新のサンプル (NHibernate 2) へのポインタは、非常にありがたいものです。

レガシー データベース (変更できない) の上にアプリケーションを構築しています。データ アクセスに Linq to SQL を使用しています。つまり、テーブルごとに (Linq to SQL) クラスがあります。

ドメイン モデルがデータベースと一致しません。たとえば、 と という名前の 2 つのテーブルがあるため、Usersとという名前Employeesの 2 つの Linq to SQL クラスがUserありEmployeeます。しかし、私のドメイン モデルではUser、いずれかのテーブルのいくつかのフィールドを含むクラスが必要です (ただし、これらのテーブルの他の多くのフィールドは気にしません)。

リポジトリをどのように設計すればよいかわかりません:

• リポジトリは、Linq から SQL クラスへのマッピング (例: ) をドメイン クラス ( ) に実行UserしEmployee、ドメイン クラスUserのみをアプリケーションに返す必要があります。
• または、私のリポジトリはLinqをSQLクラスに返し、マッピングを呼び出し元に任せるべきですか

最初のアプローチの方が理にかなっているように思えますが、これは私のリポジトリを実装する正しい方法ですか?

先日、Greg Young による DDD のスクリーン キャストを見て、保存したときの状態ではなく、オブジェクトのすべての状態遷移を永続化し、現在の状態を取り戻すためにこれらすべてのメッセージを「再生」してロードすることについて話しました。とても興味深いアイデアのように思えましたが、私はこの特定のものを何と呼んでいるのかについて行き詰まっています! それについてもっと読みたいのですが、本当の名前がないとまともな結果を得るのに苦労しています.

誰でも私を啓発できますか？

スクリーン キャストは @ http://www.infoq.com/presentations/greg-young-unshackle-qcon08です。

集約ルートに関する私の理解が正しければ、ルートはその「子」の 1 つを削除する責任も負う必要があります。それは一見、次のようなものに変換されます。

これにより、コレクションから効果的に削除されます。しかし、これはどのように持続されますか？私の ORM の UnitOfWork は、そのコレクションで何かが欠落していることを検出し、データベースから削除することになっていますか?

代わりに、RemoveOrderLine を OrderRepository のメソッドにする必要がありますか?

DDD の誇大宣伝に触発されて、データベースがまったくないふりをしてクラスを設計しました。次に、NHibernate を使用して、クラスをデータベース テーブルにマップしました。クラス グラフの一部は次のようになります。注文 (hasmany)--> 製品 (belongsto)--> 販売者 特定の販売者に発注されたすべての注文を取得します。私はコードを持っています：

きれいではありませんが、単体テストでは機能しました。実際のデータをデータベースに注入し始めるまで、私は幸せでした。吐きたいほどの出来の悪さ。そこで、リポジトリ コードについて少し調査を行いました。当然のことながら、必要な注文を見つけるには、Order テーブルからすべてのデータを取得し、Product テーブルからすべてのデータを取得し、Seller テーブルから一部のデータを取得する必要がありました。

だから、ここに私の問題があります。データベース領域の完全なダミーとして、リポジトリ コードがひどく臭いことはわかっていても、リポジトリ コードを改善する方法がわかりません。そのため、Order クラスを変更して Seller クラスへの参照を持たせ、hql を使用して Where 句を追加し、パフォーマンスを向上させたいと考えています。しかし、データベースの問題によるクラス構造の変更は、DDD の原則に違反しているようです。

特に私のリポジトリコードを改善する上で、あなたの提案は何ですか? ActiveRecord と hql に Linq を試しました。しかし、それらを機能させることができませんでした。

リポジトリパターンを適切に使用する方法について頭を悩ませようとしています。Aggregate Root の中心的な概念が次々と出てきます。Web とスタック オーバーフローの両方で集約ルートとは何かについてのヘルプを検索すると、それらに関する議論と、基本定義が含まれているはずのページへの無効なリンクが見つかります。

リポジトリ パターンのコンテキストでは、集約ルートとは何ですか?

リポジトリからの製品のリストがあります。十分に単純です。次に、フィルタリングと並べ替えを追加します。ソートは、リポジトリ内で実行しても効率が向上しないため、リポジトリ外で実行される可能性があります (推測)。関心のあるレコードのみをロードしたいので、リポジトリの外でフィルタリングを行うことは想像できませんでした。フィルターデリゲートを作成してリポジトリに渡したいと思います。

以下のコードは疑似 C# コードです。ソート/フィルタリングすると、機能するコードはどのようになりますか?

以下のプロセスは、デリゲートをリポジトリに渡してフィルタリングすることを中心にしています。

(これが MS MVC の場合、このコードはコントローラーに存在します):

フィルターをセットアップします。

並べ替えをセットアップします。

ビュー モデルを返します。

ご覧のとおり、このコードにはいくつかの助けが必要です。これを機能させるソートおよびフィルタークラスコード、または外部ソースへのリンクを本当に探しています。並べ替えとフィルタリングは、DDD および設計パターン内の標準的な方法であると想定しているため、質問です。Product は昔ながらの e コマース製品であると仮定してください ;) Rob Conery の Ajax ノートはこちら

ありがとう。

DDD とリポジトリ パターンについて質問があります。

Customer 集約ルート用の Customer リポジトリがあるとします。Get & Find メソッドは、Address などのオブジェクトを含む完全に設定された集計を返します。すべて問題ありません。しかし、ユーザーが UI で顧客を検索するときは、集約の「要約」、つまり要約された情報を含むフラットなオブジェクトだけが必要です。

これに対処する 1 つの方法は、通常どおりリポジトリで find メソッドを呼び出し、アプリケーション レイヤーで各顧客集計を CustomerSearchResult / CustomerInfo DTO にマップし、それらをクライアントに送り返すことです。

しかし、これに関する私の問題はパフォーマンスです。各 Customer 集計では、すべての関連付けを設定するために複数のクエリが必要になる場合があります。したがって、私の検索基準が 50 人の顧客と一致した場合、DB では、必要のないデータを取得する可能性があるため、かなりのヒットになります。

もう 1 つの問題は、最後の注文日など、Customer の集計ルート境界の外側にある顧客に関する要約データを含めたい場合があることです。注文には独自の集計があるため、顧客の注文情報を取得するには、OrderRepository を呼び出す必要があり、パフォーマンスも低下します。

だから今、私は2つのオプションが残っていると思います:

1. 1 つの効率的なクエリを実行して、これらの集計オブジェクトのリストを返す追加の Find メソッドを CustomerRepository に追加します。

2. 1 で説明した find メソッドだけを持つ、専用の読み取り専用の CustomerInfoRepository を作成します。

しかし、どちらも DDD の原則に反しているように感じます。私のリポジトリは、T : IAggregateRoot という一般的なベースから継承します。これらの要約情報オブジェクトは集計ではなく、T とは異なる型であるため、実際には #1 は設計に反します。

おそらく #2 では、IAggregateRoot 制約なしで抽象的な SearchRepository を作成しますか?

私のドメインには多くの同様のシナリオがあります。

このシナリオをどのように実装しますか?

ありがとう、デイブ

アップデート

Theo の回答を読んだ後、オプション #2 を使用して、これらのシナリオ向けのインフラストラクチャ内に特殊な SearchRepository を作成すると思います。アプリケーション層 (WCF サービス) は、ドメイン エンティティを DTO にマッピングするのではなく、要約 DTO を直接設定するだけのこれらのリポジトリを呼び出すことができます。

**** アップデート 2 ****

1年以上前にこれを尋ねましたが、この正確な問題を解決することを目的としたCQRSを発見したことを付け加えたいと思いました。Udi Dahan ( http://www.udidahan.com/ ) と Greg Young ( http://codebetter.com/gregyoung/ ) は、それについて多くのことを書いています。DDD を使用して分散アプリケーションを作成する場合は、CQRS が最適です。