個別の「ドメイン」レイヤーを使用する必要がありますか？
私はドメイン層とDDDについてたくさん読んでいます。しかし私はそれについてまだ混乱しています。私にはそれらはビジネスクラスの派手な名前のように見えますが、アプリケーションドメインに向かってモデル化されていますが、私が扱ってきたほとんどのプログラマは、ビジネスオブジェクト/エンティティを作成し、実際のアプリケーションオブジェクトにできる限り近づけてモデル化しようとします。
だからここに質問があります。 Asp.net Web APIアプリケーションでは、特定の入力と結果として実行されるいくつかのロジックに基づいて、さまざまなテーブルから大量のデータ（主にGETリクエスト）を取得することに重点が置かれていますが、ドメインレイヤーとオブジェクト？
** DDDについて読んだときに問題になるもう1つの点は、DALとBLLの両方がドメインレイヤーにリンクしているため、将来アプリケーションの特定の部分を更新するときに依存関係の問題が発生する可能性があることです。
あなたが説明しているビジネスオブジェクトは、DDDの意味で実際にはドメインオブジェクトではないと思います。DDDを適用している場合、ビジネスロジックはドメインオブジェクト自体に含まれます。あなたが説明しているエンティティ（ビジネスロジックが別のレイヤーにある）は Anemic のようです。
DDDを使用するかどうかを知りたい場合は、作業しているドメインが複雑で、ドメインの専門家が「 [f]として根本的に関与するかどうかを確認する必要があります。DDDは、ユーザーが関わっているドメインの深い問題に焦点を当て、心の最も良い部分はそのドメインを理解することに専念し、そのドメインの専門家と協力して、構築に使用できる概念的な形に取り組む強力で柔軟なソフトウェア。」 Eric Evans
特定の入力といくつかのロジックに基づいてさまざまなテーブルからのデータを基本的に表示しているという事実は、ドメインがDDDの適用を保証するほど複雑ではないことを私に信じさせるでしょう。
最後の懸念に対処するために、一般的なDDDアーキテクチャにはドメインレイヤーへのDALおよびBLLリンクがありません。DALは repository の背後で抽象化され、ドメインオブジェクトを公開および永続化します。ビジネスロジックはドメインオブジェクト自体に含まれ、 "BLL"は実際にはドメインオブジェクトへのアクセスにリポジトリを使用するサービスまたはアプリケーションレイヤーであり、 "アプリケーションアクティビティ。ビジネスロジックを含まない。ビジネスオブジェクトの状態は保持しませんが、アプリケーションタスクの進行状態を保持できます "。 （本から ドメイン主導の設計すぐに30ページ ）