9

アプリケーション サービスに関する私の理解では、アプリケーション サービスはドメインとユーザー インターフェイスの間を結び付けます。つまり、ドメインで操作を実行するコントローラーとして機能します。

アプリケーションに次のプロジェクト レイアウトがあります。

  • ドメイン コア
  • インフラストラクチャー
  • サービス インターフェイス
  • ウェブ UI
    • ビューモデル
    • ビュー
    • コントローラー
    • サービス (アプリケーション サービス)

私のService Interfaces嘘はWeb UIプロジェクトの外にあります。次に、Web UIプロジェクトで、サービス インターフェイスを の下に実装しますServices

ただし、この構造には少し欠陥があり、これを実際に使用すると循環依存が生じます。このリンクのアーキテクチャをたどろうとしました: https://www.develop.com/onionarchitecture

特定のサービスについて、ビュー モデルを渡し、ビュー モデルに基づいてドメインで操作を実行し、更新されたビュー モデルを返します。このアプローチは間違っていますか?

アプリケーションサービスは本質的にビューモデルをパラメータとして取り、必要に応じてドメインとビューモデルの詳細を更新し、ビューモデルを返すという私の理解は正しいですか?

または

アプリケーション サービスは、C# のデータ型とドメイン モデルのみをパラメーターとして処理し、同じデータ型を返しますか? つまり、ビュー モデル内の情報を取得または設定しません。実際には、ビューモデルが存在することを知りません。

厳密な DDD アプローチからの最良のアプローチは何かを明確にする必要があります。

4

1 に答える 1

4

質問への回答: はい、その通りです。MVC アプリケーションの場合、ViewModel を受け取って返すレイヤーを設計し、内部でドメインを操作できます。

ソリューション構造の良い例は、Dino Esposito hereによって作成されています。私は自分のプロジェクトをこの構造に採用し、それがより明確になりました。私の意見では、タマネギのアーキテクチャは小規模または中規模のプロジェクトでは複雑すぎるということです。

于 2015-08-21T03:15:47.780 に答える