DDD限定コンテキストによるエンティティ構成管理

Question

hereのように、複数のDDD限定コンテキストを実装しようとしています。

Iは、適切なFluentAPIマッピングと各エンティティのエンティティタイプの設定ファイルを持っている（EF工具を使用してリバースエンジニアリング）：これは、例えばコンテキストです。これらの構成ファイルには、関係構成も含まれています。

例えば：UserMap.cs

// Relationships 
this.HasOptional(t => t.SecurityProfile) 
    .WithMany(t => t.Users) 
    .HasForeignKey(t => t.SecurityProfileCode); 

SecurityProfileとDomainPermissionコンテキストにDbSetsありません。それらは、それぞれ、UserとModuleのナビゲーションプロパティのためにモデルに自動的に持ち込まれます。

これは私の最初の問題を引き起こします。他のコンテキストにUser（または任意の他のエンティティ）を追加するとき、私は2つのいずれかを行うに覚えている：

1. はまたSecurityProfileのモデルビルダー（および実体上の他のすべての関係）に設定を追加します

2. 明示的に何らかの形でモデルからSecurityProfileを除外します。

これはメンテナンスの悪夢になり始めています。

上記のポイント2で概説したように、エンティティグラフを明示的に「トリム」することに満足します。

ただし、エンティティ設定ファイルでリレーションシップがすでに定義されている場合は、エンティティが表示されない可能性があります。Ignore()上記の文脈OnModelCreatingためmodelBuilder.Ignore<SecurityProfile>();をしようと

はConfigureAssociations()に次のエラーを与える：

のSystem.InvalidOperationException：ナビゲーションプロパティ「をSecurityProfile」タイプ「ユーザー」に関する宣言されたプロパティではありません。それがモデルから明示的に除外されておらず、有効なナビゲーションプロパティであることを確認します。

私が考えることができる唯一の解決策は、基本構成クラスを継承し、各コンテキストの関係設定を上書きすることです。私たちが30-40 +別の文脈で終わるかもしれないことを考えれば、これはメンテナンスの悪夢になるかもしれません。

また、コンテキストごとに非常に固有のエンティティモデルを持つこともできますが、これもまた、エンティティクラスの爆発と重複した構成の潜在的なメンテナンスの問題につながります。

制限付きコンテキストの実装時に、エンティティとそのエンティティ構成を最適に管理して維持するにはどうすればよいですか？

Answer 1

によるコメントはあまりにも長いビットにここに追加しました：

それは非常に（国連のですか？）おもしろいことに、あなたが言及している記事は、明らかに新しい流行語であるDDDに言及し、その後DTO/POCOオブジェクトをコンテキスト内でどのように永続化できるかを示して、バンドワゴンに飛び込もうとしていることに注意してください。これは絶対にDDDを行うことはありません。

ドメインドリブンデザインは、問題のドメインのubiquitous languageで表される特定のアクターの特定の問題を解決するために反復的に調査され、洗練されたカプセル化（インフラストラクチャ分離/無知）モデルです。

これらのモデルは、通常、一部の永続性モデルには直接マップされません。境界のあるコンテキスト内の集約ルーツに対して実行される操作は、通常、トランザクションの境界に沿って行われます。

DDDが必要とするもの、境界のあるコンテキストおよび集約されたルーツについて正しく理解するために、skillmatter（キーワードDDD eXchange）のEric Evanのウェブキャストの一部を見ることをお勧めします。そしてその後、あなたは本当に彼の本を読むべきです、それは素晴らしい読書です。しかし、テクノロジービルディングブロックに集中するという罠に陥るのではなく、彼の最近の展望（これらのウェブキャストで表現されている）が必要です。