5
Entity Frameworkによるドメイン駆動設計の落とし穴
私が研究したDDDに関するチュートリアルの多くは、主に理論をカバーしています。それらはすべて基本的なコード例（Pluralsightなど）を持っています。 Webでは、EFを使用したDDDをカバーするチュートリアルを作成しようとする試みも数人います。それらをほんの少しだけ調べ始めると、それらは互いに大きく異なることにすぐに気づきます。一部の人々は、アプリを最小限に保ち、追加のレイヤー（EFの上にリポジトリなど）を導入することを避けることを推奨します。他の人々は、追加のレイヤーを決定的に生成し、多くの場合、DbContext集約ルートに注入することによってSRPに違反します。 私が意見に基づく質問をしている場合、私はひどくお詫びしますが... 実践に関しては、Entity Frameworkは最も強力で広く使用されているORMの1つです。残念ながら、DDDに関する包括的なコースは見つかりません。 重要な側面： Entity Frameworkは、UoW＆リポジトリ（DbSet）をすぐに使用できるようにします EFでは、モデルにナビゲーションプロパティがあります EFでは、すべてのモデルが常にオフで使用できますDbContext（それらはとして表されますDbSet） 落とし穴： あなたがすることはできません、あなたのモデルは、ナビゲーションプロパティを持っており、それが彼らとのコールを変更することができます-あなたの子供のモデルのみ集約ルートを経由して影響を受けている保証しますdbContext.SaveChanges() でDbContext、あなたはこのように、あなたのすべてのモデルにアクセスすることができます回避集約ルートを あなたは、経由ルートオブジェクトの子へのアクセスを制限することができますModelBuilderでのOnModelCreating法分野としてそれらをマークすることにより、（私はまだそれがDDDについて移動する正しい方法だとは思わないそれに加えて、これは将来的ににつながる可能性の冒険の種類何を評価するのは難しい- 非常に懐疑的） 矛盾： Aggregateを返すリポジトリの別のレイヤーを実装しないと、上記の落とし穴を部分的に解決することさえできません リポジトリーの追加レイヤーを実装することにより、EFの組み込み機能（すべてDbSetがすでにレポです）を無視し、アプリを複雑にします。 私の結論： 私の無知を許してください、しかし上記の情報に基づいてください-それはエンティティフレームワークがドメイン駆動設計に適切でないか、ドメイン駆動設計が不完全で時代遅れのアプローチであるかのいずれかです。 それぞれのアプローチにはメリットがあると思いますが、私は今完全に道に迷っており、EFとDDDをどのように調整するかについて少し考えていません。 私が間違っている場合-EFでDDDを実行する方法の簡単な一連の手順を詳細に説明できますか（または適切なコード例を提供できますか）。