次のように、ソリューション エクスプローラーでさまざまなレイヤー (クラス ライブラリ プロジェクト) を分離しました。
PetaPoco マイクロ ORM を使用したいのですが、リポジトリ レイヤーに PetaPoco を追加するよう提案されました。提案どおり、PetaPoco をリポジトリ プロジェクトに追加し、データベースからモデルを生成しました。これで、自動生成された POCO がリポジトリに存在します。
私がフォローしていないのは、DDDを実装したいときです。モデル、つまりビジネスレイヤーにすべてのPOCOが必要です。
WebUIレイヤーにユーザーログイン用のWebFormを追加しました。DDD を使用する場合、モデルにインターフェイスが必要ですか? Validate Login メソッドはどこに記述すればよいですか?
ドメイン駆動設計に関する Eric Evans の本を (再) 読むことを強くお勧めします。また、あなたは氏を見るべきです。本の後のエヴァンスのビデオ。DDD は、リポジトリ、データベース、アセンブリ、またはユーザー ログインに関するものではありません。
DDD が実際に探しているものではない可能性もあります。データベース上のいくつかのリポジトリの上にいくつかのエンティティ/アプリサービスの上にUIを配置した階層化されたアプローチを探しているようです。構築するものによっては、実際にはこれだけで十分な場合があります。
PetaPoco を使用したい場合、および「orm」がデータベースから「モデル」を生成する場合、それらを異なるプロジェクトに分離することはあまり意味がありません。モデルが orm によって生成されるという事実 (および将来的に再生成する必要がある可能性があるという事実) により、モデルは orm と完全に結合されるため、別のアセンブリに移動しても何も得られません。
ValidateLogin の質問に答えるには、すべての認証関連のコードを、他のレイヤーと直交する (垂直) インフラストラクチャ レイヤーに移動することをお勧めします。アプリのユーザーは、必ずしも「エンティティ」である必要はありません。認証を処理するモデル レイヤーにアプリ サービスを配置することもできますが、通常、認証はビジネス上の問題ではなく、インフラストラクチャの問題であることがわかりました。
最後に、そのようなアーキテクチャの落とし穴と長所をよく理解してから、構築するものに適しているかどうかを判断することをお勧めします。一方で、DDD の構築は安価ではないことに注意する必要があります。また、(Evand 氏が言ったように) 最初の数回はおそらくうまくいかないでしょう。