私はできる限り物事を非常にシンプルに保つように努めているため、通常は次のような方法でうまくいきます。
Myapp.Domain - ドメイン固有のすべてのクラスがこの名前空間を共有します
Myapp.Data - ドメインからデータベースを抽象化するシン レイヤー。
Myapp.Application - すべての「サポート コード」、ロギング、共有ユーティリティ コード、サービス コンシューマなど
Myapp.Web - Web UI
したがって、クラスはたとえば次のようになります。
- Myapp.Domain.Sales.Order
- Myapp.Domain.Sales.Customer
- Myapp.Domain.Pricelist
- Myapp.Data.OrderManager
- Myapp.Data.CustomerManager
- Myapp.Application.Utils
- Myapp.Application.CacheTools
等。
作業を進める上で心に留めておきたいのは、「ドメイン」名前空間がアプリケーションの実際のロジックをキャプチャするものだということです。そこで、「ドメインの専門家」(アプリケーションを使用する予定の人物) と話せる内容について説明します。彼らが言及したために何かをコーディングしている場合、それはドメイン名前空間にある必要があります。
このため、複雑すぎるオブジェクト階層を作成することにも注意を払っています。理想的には、ドメイン モデルのやや簡略化された図は、非コーダーが直感的に理解できるようにする必要があります。
この目的のために、私は通常、パターンについて詳細に考えることから始めません。標準的なオブジェクト指向の設計ガイドラインに従って、ドメインをできる限り単純にモデル化するようにしています。オブジェクトである必要があるのは何ですか? それらはどのように関連していますか？
私の考えでは、DDD は複雑なソフトウェアの処理に関するものですが、ソフトウェア自体が最初から非常に複雑でない場合、DDD のやり方が複雑さを取り除くのではなく、複雑さを追加する状況に簡単に陥る可能性があります。
モデルがある程度複雑になると、特定のものをどのように編成する必要があるかが見え始め、どのパターンを使用するか、どのクラスが集約であるかなどがわかります。
私の例では、 Myapp.Domain.Sales.Order は、インスタンス化されたときに、顧客オブジェクトや注文明細のコレクションなどの他のオブジェクトが含まれる可能性が高く、注文明細にのみアクセスするという意味で、集約ルートになります。 order オブジェクトを介してその特定の注文について。
ただし、物事を単純にするために、他のすべてを含み、他の目的を持たない「マスター」オブジェクトは使用しないため、注文クラス自体にアプリケーションで役立つ値とプロパティが含まれます。
したがって、次のようなものを参照します。
Myapp.Domain.Sales.Order.TotalCost
Myapp.Domain.Sales.Order.OrderDate
Myapp.Domain.Sales.Order.Customer.PreferredInvoiceMethod
Myapp.Domain.Sales.Order.Customer.Address.Zip
等