アプリケーション層vsドメイン層？
私はEvansによるDomain-Driven Designを読んでおり、階層化されたアーキテクチャについて説明する部分にいます。アプリケーション層とドメイン層は異なり、分離する必要があることに気づきました。私が取り組んでいるプロジェクトでは、それらは混ざり合っており、本を読むまでは違いを知ることができません（そして、今ではそれが非常に明確であるとは言えません）。
私の質問は、どちらもアプリケーションのロジックに関するものであり、技術面とプレゼンテーション面の問題がないはずなので、これら2つの境界を描くことの利点は何ですか？
私は最近DDDを自分で読みました。このセクションにたどり着いたとき、エヴァンスが行ったのと同じ4層アーキテクチャを発見したことを知って嬉しく驚きました。 @lonelybugが指摘したように、ドメイン層はシステムの他の部分から完全に分離されている必要があります。ただし、UI固有の値（クエリ文字列、POSTデータ、セッションなど））をドメインオブジェクトに変換する必要があります。ここでアプリケーションレイヤーが機能します。翻訳は、 UI、データレイヤー、ドメイン間を行き来し、システムの他の部分からドメインを効果的に隠します。
現在、ほとんどすべてのロジックがコントローラーにあるASP.NET MVCアプリケーションがたくさんあります。これは、古典的な3層アーキテクチャを実装する試みの失敗です。コントローラーは、UI固有の問題が非常に多いため、単体テストが困難です。実際、「Http Context」の値に直接関係しないようにコントローラーを作成することは、それ自体が深刻な課題です。理想的には、コントローラーは単に変換を実行し、作業を調整し、応答を吐き返す必要があります。
アプリケーション層で基本的な検証を行うことも理にかなっています。ドメインは、そこに入る値が意味をなすと想定しても問題ありません（これはこの顧客の有効なIDであり、この文字列は日付/時刻を表しますか）。ただし、ビジネスロジックを含む検証（過去に飛行機のチケットを予約できますか？）は、ドメインレイヤー用に予約する必要があります。
Martin Fowlerは、最近のドメインレイヤーが最近どのように フラットであるかについてコメントしています 。ほとんどの人はアプリケーション層が何であるかさえ知りませんが、多くの人が、さまざまなドメインオブジェクトの動作を調整するかなり単純なドメインオブジェクトと複雑なアプリケーション層を作成していることに気付きます。私自身、これについて有罪です。一部の本があなたに言ったので、重要なことはレイヤーを構築することではありません。考えは、責任を識別し、それらの責任に基づいてコードを分離することです。私の場合、「アプリケーション層」の種類は、単体テストを増やすにつれて自然に進化しました。
マーティンファウラーのエンタープライズデザインのパターンを基に、最も一般的なレイヤーは次のとおりです。
プレゼンテーション-これらは、アプリケーションの対話インターフェイスを生成するビュー、プレゼンテーションテンプレートです（アプリケーションがWebサービスまたはRMIを介して他のシステムからアクセスされるため、ユーザーインターフェイスではない可能性がある場合は、対話を使用しています）。これには、アクションの実行方法と実行方法を決定するコントローラーも含まれます。
ドメイン-ここにビジネスルールとロジックが存在し、ドメインモデルが定義されます。
データソース-これはデータマッピングレイヤー（ORM）とデータソース（データベース、ファイルシステムなど）です。
3つのレイヤー間の境界をどのように描画しますか。
モデルまたはドメインオブジェクト内にプレゼンテーション固有のロジックを配置しないでください
ページやコントローラー内にロジックを配置しないでください。つまり、オブジェクトをデータベースに保存したり、データベース接続を作成したりするロジックです。これにより、プレゼンテーションレイヤーが脆弱になり、テストが困難になります。
モデルからデータソースのアクセスとアクションを分離できるORMを使用します
シンコントローラー-脂肪モデルパラダイムに従ってください。コントローラーは、実行プロセスではなく実行プロセスを制御するためのものです。詳細は http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models- skinny-controllers / および http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model モデル、ビュー、およびコントローラー、
ドメインレイヤーは、アプリケーションのbusinessをモデル化します。これは、そのルールの明確な解釈であり、コンポーネントのダイナミクスであり、任意の瞬間の状態を含みます。
アプリケーションレイヤーは、特定のアプリケーションタスクを実行するために実行する必要があるジョブを定義する「心配」です。主に、それは必要なドメイン作業を委任する責任がありますand他の（外部または非）サービスと相互作用します。
exampleの場合、金融ソフトウェアアプリケーションには、モデルエンティティ（DDD [89]で定義されているエンティティ）の状態を変更するためのユーザー操作があります。
- 「事業責任者は財務提案を承認できます」。
しかし、アプリケーションプロセスとして、この操作のすべてのモデルの結果に加えて、アプリケーションの他のユーザーに内部通信を送信する必要があります。この種の作業は、アプリケーション層で「調整」されます。ドメイン層がメッセージングサービスを指示することを考えて欲しくない。 （そして、これはプレゼンテーション層の責任ではありません）。いずれにせよ、確かなことが1つあります。ドメインレイヤーはすべてコアビジネスに関するものであり、プレゼンテーションレイヤーはすべてユーザーコマンドの解釈と結果の表示に関するものであるため、新しいレイヤーが必要です。
ノート：
- Businessは、その意味の複数の解釈につながることが多い単語の1つですが、DDDで多くの例と話題について見つけることができます。
- DDDは、Eric EvansによるDomain-Driven Designブックの略で、ページ番号は角括弧内の番号です。
ドメインレイヤーは分離レイヤーとして設計する必要があります。つまり、ビジネスロジックとルールは、（アプリケーションレイヤー、プレゼンテーションレイヤー、インフラストラクチャレイヤーの）コードの変更の影響を受けません。
アプリケーション層は、システム（アプリケーション）インターフェース（これをAPIまたはRESTfulのように考える）が実行できる機能に関するいくつかの機能を提供するように設計されていると想定されています。たとえば、ユーザーはシステムにログインでき、このアプリケーションアクション（ログイン）では、アプリケーションレイヤーコードがドメインレイヤー（またはインフラストラクチャレイヤー）のクライアントコードになり、ユーザードメインオブジェクトを取得して、このオブジェクトのメソッドを適用して「ログイン」機能。
アプリケーション層は、分離層としても設計する必要があります。つまり、アプリケーションの動作は、（プレゼンテーション層、ドメイン層、インフラストラクチャ層の）コードの変更の影響を受けません。
- アプリケーション層とドメイン層の両方が実装の範囲に含まれます。
- アプリケーション層はAPIとして機能します。
- ドメインレイヤーはAPIの実装として機能し、ビジネスロジックが含まれているため、ビジネスロジックレイヤーとも呼ばれます。
ドメインドリブンモデリングのポイントは、必須ドメインモデルを分離し、他のレイヤーへの依存や他のアプリケーションの懸念なしに存在させることです。
これにより、気を散らすことなく（UIと永続化サービスの間の調整など）ドメイン自体に集中できます。
これらの境界の主な理由は 懸念の分離 です。データストアにアクセスするコードは、データストアへのアクセスについてのみ考慮する必要があります。データにルールを適用する責任はありません。さらに、UIは、UIのコントロールの更新、ユーザー入力からの値の取得、ドメインレイヤーが使用できるものへの変換などを担当する必要があります。ドメインレイヤーによって提供される操作を呼び出して、必要なアクションを実行する必要があります（このファイルを保存するなど）。呼び出されるWebサービスは、伝送媒体からドメイン層が使用できるものに変換し、ドメイン層を呼び出す必要があります（ほとんどのツールがこの作業の多くを行います）。
この分離は、適切に実装されている場合、他のユーザーに影響を与えることなくコードの一部を変更する機能を提供します。たとえば、返されたオブジェクトのコレクションの並べ替え順序を変更する必要があるかもしれません。データ操作を担当するレイヤー（通常はビジネスロジックレイヤー）がこれを処理することがわかっているので、コードを変更する必要がある場所を簡単に特定できます。データストアからの取得方法、またはドメインを使用するアプリケーション（上記の例のUIとWebサービス）を変更する必要はありません。
最終的な目標は、コードをできるだけ簡単に保守できるようにすることです。
補足として、ドメインの特定のレイヤーに鳩の巣穴を開けないものもあります（ロギング、検証、承認など）。これらのアイテムは一般に横断的関心事と呼ばれ、場合によっては、他のすべてのレイヤーが認識して使用できる、それ自体が独立したレイヤーとして扱うことができます。
個人的には、レイヤードアプローチは時代遅れであり、サービスアプローチの方が優れていると思います。砂の中に誰が何をするかというはっきりとした線が引かれていますが、階層的である必要はありません。たとえば、アプリケーションの観点から、注文サービス、請求サービス、配送サービスはすべてのドメインを表しており、上記で説明した責任の延期はこのコンテキストでも有効ですが、変更されただけです。ドメインが複数の場所に存在し、懸念の分離の概念をさらに活用していること。