私は、アプリケーション サービスとドメイン サービスの両方である、サービス層のドメイン主導の設計概念に頭を悩ませようとしています。私が遭遇した事実上すべての例は、データベースを使用した CRUD アプリケーションに関係しています。これらの概念が、この質問のために選択したサンプル アプリケーション (.NET/C# で開発された Microsoft Paint のクローン) のようなグラフィカル アプリケーションにどのようにマッピングされるかを理解するのに苦労しています。
DDD のサービス層の基本概念と詳細な説明を読みました。次のアプリケーション層を選択しました。
インフラ（分野横断）
- ロギング
データ (ファイルシステム)
- BitmapImage、PngImage など
ドメイン
- キャンバス、画像、選択範囲、シェイプ、ブラシなど
応用
プレゼンテーション (ローカル クライアント WPF)
- ビュー
- ビューモデル
私がデザインしようとしているユース ケースの 1 つは、ユーザーがキャンバス上に四角形を描くことです。私が読んだことから、ユースケースはいくつかのドメインオブジェクトの協力を必要とするため、ドメインサービスである DrawingService は理にかなっています。
もう 1 つの使用例は、ユーザーが表示するファイルをロードすることです。繰り返しますが、私が読んだことから、このユース ケースはコマンドとワークフローであるため、アプリケーション サービス FileLoadingService は理にかなっています。
Martin Fowler が説明しているように、Microsoft Paint は、ここではテーマ別の動作に基づいたサービス サブシステムを保証するのに十分なほど複雑であると私は信じています。ただし、アプリケーションが成長するにつれて、サービス レイヤーをリファクタリングして、CanvasService、SelectionService などのドメイン モデルのパーティションに分類することができます。複数のサービスが連携しなければならない今、別の抽象化レイヤー、おそらくアプリケーション ファサードが必要になるでしょうか?
更新 1:
最初のコメントは、DDD アーキテクチャが描画アプリケーションに適していないことを示唆しています。代替案はありますか？