entity-framework - DDDでの非ビジネスロジックデータベースアクセス

Question

DDDから始めます。すべてのドメインエンティティとそのロジックは、リポジトリインターフェイスとともにドメインレイヤーに保持する必要があることを理解しています。私のアプリケーションでは、実行時にユーザーインターフェイス（プレゼンテーション層）の一部を構築するために使用されるデータをデータベースに保存します。アプリケーション層またはドメイン層で、そのようなタイプのpocoクラスとリポジトリインターフェイスをどこに保持する必要がありますか。これらのオブジェクトにはドメイン関連のビジネスロジックがないためわかりませんが、データベースからハイドレイトする必要があり、EFを使用しているため、データアクセスにはエンティティとリポジトリが必要です。ドメインレイヤー内の他のすべてのエンティティとリポジトリインターフェイスですが、DDDルールに違反しています

Answer 1

私はあなたがあなた自身の質問に答えたと思います：

私のアプリケーションでは、実行時にユーザーインターフェイス（プレゼンテーション層）の一部を構築するために使用されるデータをデータベースに保存します。

UIを提供するために使用されるデータへのアクセスは、プレゼンテーション層にカプセル化する必要があります。これは、DDDアプリケーション層がリポジトリを調整し、適切なエンティティであるドメインサービスに委任することでユースケースを実装するという点で、アプリケーション層とは異なります。これは、ドメイン層の周囲にAPIを形成します。異なるプレゼンテーション実装で同じアプリケーションサービスを使用できます。

ただし、プレゼンテーション層の実装が異なれば、必要なデータも異なります。したがって、プレゼンテーションデータアクセスをプレゼンテーション層に直接配置します。これは、DDDシナリオ専用ではないEFを使用して実装できます。

Answer 2

アプリケーション層。ドメインを無傷で分離してください。

Answer 3

これを考える良い方法はこれです-パフォーマンス上の理由でEFをストアドプロシージャに置き換える必要がある場合は、ドメインコードを変更する必要はありません。したがって、インターフェイスの背後に隠して交換可能にする必要があるブロックをブロックするものはすべてです。

リポジトリはドメインロジックの一部になることができます。しかし、すべきではないのは永続性のメカニズムです。これは、DALサービスまたは他のオブジェクトに簡単にカプセル化できます。もちろん、これらはIDALServiceインターフェイスにプログラムされています。したがって、永続性を切り替える必要がある場合（たとえば、EFからNoSQLソリューションに移行する場合）、IDALServiceインターフェースを実装する代替バージョンを作成するだけで、準備は完了です。リポジトリは引き続きそれらの内部でロジックを実行できますが、現在はそれらを格納するための新しい方法を使用しています（これは制御の反転のアイデアです）。

POCOオブジェクトに関しては、DDDでの本当の問題は、それらが何を表すかということです。それらは永続化する必要のあるエンティティですか？それらはオブジェクトを大切にしていますか？テクノロジー（EF）にオブジェクトモデルの構造を決定させないでください。代わりに、アプリケーションスコープに変換する手段を提供してください。