問題タブ [domain-driven-design]

エンティティ Foo があり、別のエンティティ Bar のリストが含まれているとします。Bar は Foo を直接参照する必要がありますか? つまり..

または、Bar クラスで Foo への参照を省略しますか?

私はその参照を除外することに傾いていますが、ここで正しいアプローチは何だろうと思っていましたか?

ドメイン駆動設計の複雑な集合体の検証にどのように対処しますか？ビジネスルール/検証ロジックを統合していますか？

私は引数の検証を理解し、モデル自体に添付できるプロパティの検証を理解し、メールアドレスまたは郵便番号が有効であること、または名の長さが最小および最大であることを確認するなどのことを行います。

しかし、複数のモデルを含む複雑な検証についてはどうでしょうか。通常、これらのルールとメソッドをアーキテクチャ内のどこに配置しますか？そして、それらを実装するために使用するパターンはありますか？

私は DDD とそれが MVC にどのように関係するかについて頭を悩ませようとしていますが、エンティティの識別に関しては問題があります。

特に、プレゼンテーション、ドメイン、およびデータ モデルを厳密に分離するようにしています。ここでの問題は、これらの境界を越えてエンティティの識別を保持する方法にあります。明確にするために、異なるコンテキストで同じエンティティを表すために別々のクラスを使用しています。 「shipment_request」データベース テーブル (私のデータ モデル)。

「ID」プロパティ (ShipmentRequestId など) を使用すると、達成しようとしている分離に違反するように感じます。この ID プロパティはデータベースの問題であり、ドメインの問題ではないためです。レイヤー間で同じオブジェクトを渡したくありません。これは、不要なデータをプレゼンテーションレイヤーに渡すことを意味するためです。

この分離を維持しながら、これらのレイヤー間のアイデンティティを追跡するにはどうすればよいでしょうか?

私は新しいプロジェクトを開始しており、DDD パターンを組み込み、Linq to Entities も含めることにしました。EF の ObjectContext を見ると、Repository パターンと Unit of Work パターンの両方の機能を実行しているようです。

基になるデータ レベル インターフェイスがエンティティ表現から抽象化され、ObjectContext を介してデータを要求および保存できるという意味でのリポジトリ。

すべての挿入/更新を objectContext に書き込み、SaveChanges() を実行するときにそれらすべてを一度に実行できるという意味での作業単位。

これらのパターンの別のレイヤーを EF ObjectContext の上に置くのは冗長に思えますか? また、モデル クラスは、「部分クラス」を使用して、EF で生成されたエンティティの上に直接組み込むことができるようです。

私は DDD を初めて使用するので、ここで何か不足している場合はお知らせください。

私はドメインモデル、POCO、DDDに慣れていないので、まだいくつかのアイデアに頭を悩ませようとしています。

私がまだ理解できなかったことの1つは、ドメインモデルをシンプルでストレージに依存しないように保ちながら、データに対して豊富な方法でいくつかのクエリを実行できるようにする方法です。

たとえば、OrdemItemのコレクションを持つエンティティOrderがあるとします。なんらかの理由で最も安い注文アイテム、または現在在庫がない注文アイテムのリストを取得したいのですが。私がしたくないのは、ストレージからすべての注文アイテムを取得し、後でフィルタリングすることです（高すぎる）ので、どういうわけか「SELECT .. WHERE ITEM.INSTOCK=FALSE」タイプのdbクエリを使用することになります。そのSQLクエリをエンティティに含めたくない、またはそれがLinq2SQLのNHibernateクエリのように特定のプラットフォームに結びつくかどうかのバリエーションは必要ありません。その場合の一般的な解決策は何ですか？

私はまだ DDD に頭を悩ませていますが、私が遭遇した障害の 1 つは、個別の集計間の関連付けを処理する方法にあります。Customers をカプセル化する 1 つの集約と、Shipments をカプセル化する別の集約があるとします。

ビジネス上の理由から、Shipments は独自の集計ですが、顧客に明示的に関連付ける必要があります。私の顧客ドメイン エンティティには、出荷のリストが必要ですか? もしそうなら、リポジトリ レベルでこのリストを作成するにはどうすればよいですか? CustomerRepository と ShipmentRepository (集約ごとに 1 つのリポジトリ) があるとします。

「関係」ではなく「関連」と言っているのは、これがインフラストラクチャの決定ではなくドメインの決定であることを強調したいからです。最初にモデルからシステムを設計しています。

編集：テーブルをオブジェクトに直接モデル化する必要がないことはわかっています-それが、最初にモデルを設計している理由です。この時点では、データベースについてはまったく気にしません。これら 2 つの集計間の関連付けだけです。

インターフェースの例:

すべての EF オブジェクトで、このインターフェイスを主キーに実装する必要があります。

これは可能ですか？

私は DDD について学び始めたので、他の人がどのようにプロジェクトを編成したか知りたいと思っていました。

AggregateRoots を整理することから始めました。

MyApp.Domain (ドメイン モデルの名前空間)

MyApp.Domain.Product
- 製品
- IProductService
- IProductRepository
- など

MyApp.Domain.Comment
- コメント
- ICommentService
- ICommentRepository
- など

MyApp.Infrastructure
- ...

MyApp.Repositories
- ProductRepository : IProductRepository
- など

これで遭遇した問題は、ドメイン製品を MyApp.Domain.Product.Product または Product.Product として参照する必要があることです。また、製品の linq データ モデルと競合します....MyApp.Domain.Product.Product と MyApp.Respoitories.Product などの 2 つを区別するために、醜いコード行を使用する必要があります。

他の人がどのように DDD のソリューションを構成しているかを知りたいです...

IDE として Visual Studio を使用しています。

どうもありがとう。

ドメイン オブジェクトをクライアントに公開する方法に頭を悩ませようとしています。リッチ クライアントを使用している場合でも、Web を使用している場合でも、MVP とリポジトリ パターンを使用したいと考えています。

私が理解しようとしているのは、サーバー上にあるリポジトリとモデルを公開する方法です。状態を持つ複雑なビジネス オブジェクトを Web サービス経由で公開することは可能ですか? それとも、.Net リモーティング、EJB、COM+、DCOM など、言語/プラットフォームにとらわれない独自のテクノロジを使用する必要がありますか?

他のいくつかの制約は、複雑なドメイン オブジェクトをデータベースからロードし続けたり、操作を実行するたびにネットワーク全体に渡したりしたくないということです。いくつかの複雑なロジックは、オブジェクトの状態と組み合わせたユーザーのアクセス許可に基づいて、画面の特定の領域が無効または非表示になる可能性があることです。検証およびエラー メッセージ情報もユーザーに表示する必要があります。同じマシン上で実行されているかのように、多くのドメイン オブジェクト操作を論理的に呼び出すことができるようにしたいと考えています。

Web を使用すると、自由に制御できます。サービスの境界を越えてオブジェクトを公開する必要がないため、必要に応じてオブジェクトをリッチにすることができます。モデルを呼び出すクライアントが別のマシン上にある場合に機能する、リッチで機能する N-teir アーキテクチャを作成しようとしています。