アプリケーション サービスに関する私の理解では、アプリケーション サービスはドメインとユーザー インターフェイスの間を結び付けます。つまり、ドメインで操作を実行するコントローラーとして機能します。
アプリケーションに次のプロジェクト レイアウトがあります。
- ドメイン コア
- インフラストラクチャー
- サービス インターフェイス
- ウェブ UI
- ビューモデル
- ビュー
- コントローラー
- サービス (アプリケーション サービス)
私のService Interfaces
嘘はWeb UI
プロジェクトの外にあります。次に、Web UI
プロジェクトで、サービス インターフェイスを の下に実装しますServices
。
ただし、この構造には少し欠陥があり、これを実際に使用すると循環依存が生じます。このリンクのアーキテクチャをたどろうとしました: https://www.develop.com/onionarchitecture
特定のサービスについて、ビュー モデルを渡し、ビュー モデルに基づいてドメインで操作を実行し、更新されたビュー モデルを返します。このアプローチは間違っていますか?
アプリケーションサービスは本質的にビューモデルをパラメータとして取り、必要に応じてドメインとビューモデルの詳細を更新し、ビューモデルを返すという私の理解は正しいですか?
または
アプリケーション サービスは、C# のデータ型とドメイン モデルのみをパラメーターとして処理し、同じデータ型を返しますか? つまり、ビュー モデル内の情報を取得または設定しません。実際には、ビューモデルが存在することを知りません。
厳密な DDD アプローチからの最良のアプローチは何かを明確にする必要があります。