6

here で概説されているように、複数の DDD 境界コンテキストを実装しようとしています。これはコンテキストの例です:

サンプル コンテキスト

エンティティごとに、適切な FluentAPI マッピング (EF ツールを使用してリバース エンジニアリング) を含むエンティティ タイプ構成ファイルがあります。これらの構成ファイルには、関係構成も含まれています。

例: UserMap.cs

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

SecurityProfileコンテキスト内にありDomainPermissionません。これらは、およびそれぞれDbSetsのナビゲーション プロパティにより、自動的にモデルに取り込まれます。UserModule

これは私の最初の問題を引き起こします。User（または他のエンティティを）他のコンテキストに追加するときは、次の2つのいずれかを行うことを忘れないでください。

  1. SecurityProfileまた、 (およびエンティティの他のすべての関係)のモデル ビルダーに構成を追加します。

  2. SecurityProfileどういうわけかモデルから明示的に除外します。

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

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

Ignore()ただし、エンティティ構成ファイルで関係が既に定義されている場合、エンティティにはできないようです。

modelBuilder.Ignore<SecurityProfile>();上記のコンテキストを試行するとOnModelCreating、次のエラーが発生しConfigureAssociations()ます。

System.InvalidOperationException: ナビゲーション プロパティ 'SecurityProfile' は、タイプ 'User' で宣言されたプロパティではありません。モデルから明示的に除外されていないこと、および有効なナビゲーション プロパティであることを確認してください。

私が考えることができる唯一の解決策は、基本構成クラスを継承し、各コンテキストで関係構成をオーバーライドすることです。最終的に 30 ～ 40 以上の個別のコンテキストになる可能性があることを考えると、これはメンテナンスの悪夢になる可能性もあります。

別の方法として、コンテキストごとに非常に具体的なエンティティ モデルを使用することもできますが、これもエンティティ クラスの爆発につながり、重複した構成でメンテナンスの問題が発生する可能性があります。

境界付けられたコンテキストを実装するときに、エンティティとそのエンティティ構成を最適に管理および維持するにはどうすればよいですか?

4

1 に答える 1

1

Added here due to a bit too long for comments:

It is extremely (un?)funny to note that the article you are referring to is apparently trying to jump on a bandwagon by mentioning a new buzzword DDD and subsequently showing only how DTO/POCO objects can be persisted in a context. This has absolutely nothing to do DDD.

Domain Driven Design is primarily about behavior and encapsulated (infrastructure isolated/ignorant) models that are iteratively explored and refined to solve specific problems for specific actors and that are expressed in the ubiquitous language of the problem domain.

These models typically do not map directly on some type of persistence model, nor should they be concerned with that. Operations performed on aggregate roots within a bounded context typically will align with transaction boundaries.

I would advise you to watch some of Eric Evan's webcasts on skillsmatter (keyword DDD eXchange) in order to get the right perspective on what DDD entails, what bounded contexts and aggregate roots are. And after that you also really should read his book, it's a great read. But you need his more recent perspectives (as expressed in these webcasts), not to fall in the trap of focusing on technology building blocks.

于 2013-09-02T02:25:10.867 に答える