DDDのプレゼンテーションVSアプリケーション層

ドメインドリブンデザインのプレゼンテーションレイヤーとアプリケーションレイヤーの間に明確な線を引くことができません。

コントローラ、ビュー、レイアウト、JavaScript、CSSファイルはどこに配置すればよいですか？

アプリケーション層かプレゼンテーション層か？

そして、それらが同じレイヤーですべて一緒に行く場合、何が他のレイヤーを含みますか？空っぽですか？

誰かが「アプリケーション層」と「プレゼンテーション層」を作成して名前を付けたからといって、アプリケーションにそれらがあるはずだとは限りません。かなりの量のコードをまとめてグループ化し、このグループに名前を付けて、開発者間のコミュニケーションとコードを明確にするために、レイヤーを作成する必要があります。

DDDのポイントから。アプリケーション層は、ドメイン層ではないすべてのものです。これには、アプリケーションロジック、プレゼンテーション、アプリケーションサービスが含まれます。

DDDの観点から見ると、アプリケーション層とプレゼンテーション層には大きな違いがあります。

DDDは、DDDビルディングブロックと制限されたコンテキスト、ユビキタス言語などの概念を使用してドメインをモデル化する方法を中心にしていますが、アプリのさまざまなレイヤーを明確に識別して分離することは依然として重要です。

アーキテクチャは、成功するDDDアプリの実装に大きな役割を果たします。最近話題になった有名な建築は、タマネギ建築です。

この設計では、UI /プレゼンテーション層とアプリケーション層が明確に分離されています。2をマージすると、2つのレイヤーが密接に結合し、明確な個別の懸念と責任が生じます。

プレゼンテーション層は、プレゼンテーションロジックのみを格納する必要があります。知識が多すぎるスマートUIは避けてください。これは主に、CSS、JS、テンプレート、フォーム、および応答オブジェクトと要求オブジェクトに関連するすべてに加えて、MVCのコントローラーとビューを収容します。

プレゼンテーションを通じて発行されたアクションは、コマンドを通じてアプリケーション層に委任されます。アプリケーション層には、アプリケーションロジックが含まれています。通常はユースケースにマッピングされます。これには、ユースケースを満たすためにシステムが何をすべきかが含まれています。一般的なアプリケーションサービスは、リポジトリに集約を返すように要求し、その集約に対してアクションを呼び出します。

Vaughn VernonのIDDDのサンプルプロジェクトをご覧ください

ドメイン駆動設計は、プレゼンテーション層またはアプリケーション層とは関係ありません。DDDは、ドメイン層に主に焦点を当てた方法論です。つまり、DDDはドメインレイヤーを除いて他のレイヤーに関する制約を課しません。また、他の方法論の文脈であなたの質問も尋ねられる可能性があります。

とはいえ、DDDアプリケーションに4層アーキテクチャを使用することは非常に一般的です。レイヤーとその用途を示すアプリケーションの例を以下に示します：DDDSampleアーキテクチャー。したがって、このアーキテクチャを使用することを選択した場合、ビューとレイアウトはインターフェース層に移動し、コントローラーは、インターフェースに依存しない場合はアプリケーション層に移動します。

DDDは制約を課さないと述べたように、他の種類のアーキテクチャを選択することもできます。さまざまな構造を持ちながら、DDDアプリケーションにも使用できる多くのMVCフレームワークがあります。次に、もちろん、それに応じてビューとレイアウトを配置します。