3

私は最初のビジネス プロジェクト (.NET) を開始し、DDD の原則に従おうとしています。ソース コードと名前空間を編成するためのガイドラインや一般的なパターンはありますか?

たとえば、ドメイン オブジェクトは名前空間などに配置されますMyProject.Domainか? 具体的な実装とインターフェイスを分離しますか? 異なる名前空間で？別のフォルダ？さまざまなソリューション？

これの多くは主観的であり、プロジェクトのサイズに依存していることはわかっていますが、比較的小さいが拡張可能な n 層プロジェクトを開始するためのいくつかの指針または提案が役立つでしょう.

4

2 に答える 2

2

DDD アプリケーションのソリューションを構成するための正しい方法はたくさんあるので、自由に実験してください。個人的なソリューションのレイアウトを数回変更しました。詳細は使用するテクノロジーに依存すると思いますが、全体的な組織はまったく同じです。

  • 境界付けられたコンテキストごとに 1 つのソリューション
  • モデル (エンティティ、値オブジェクト、リポジトリ インターフェイスなど) を含む 1 つのドメイン プロジェクト
  • NHibernate マッピング、リポジトリ実装、および NHibernate 固有の型を含む 1 つの Domain.Persistence (または DataAccess) プロジェクト。複数の永続レイヤーを持つ真剣な計画がある場合は、それらに Domain.Persistence. という名前を付けることができます。
  • アプリケーション層コード (サービス) を含む 1 つのアプリケーション プロジェクト
  • 任意の数の UI または Windows サービス プロジェクト

私のDDDSample.Netプロジェクトを見てください。同じ問題に対する DDD ソリューションの多くのバリエーションが含まれています。最も典型的な単純なものを説明しましたが、より複雑なものがあります。具体的には次のとおりです。

  • 複数のレイヤーを持つモデル
  • CQRS システム
  • イベント ソーシング CQRS システム

それが役立つことを願っています。

于 2010-05-31T03:55:43.213 に答える
1

私もこれは初めてですが、これが私がやったことです。

私たちのプロジェクト組織のルートは私たちの会社名です。会社と呼んでください。プロジェクトは次のように配置されます。

  • Company.Core にはいくつかの名前空間があります。

    .Data は、DAL のインターフェイスを定義します

    .Repository は、リポジトリの基本インターフェイスを定義します

  • Company.Data は DAL の具体的な実装です

  • Company.Domain はドメイン オブジェクトであり、リポジトリ インターフェイスが定義されている場所です。

  • Company.Repository は、リポジトリの具体的な実装です

  • Company.Tests には多くの名前空間があります。

    .Data は DAL をテストし、.Data.Mock はそれをモックします。

    .Repository はリポジトリをテストし、.Repository.Mock はリポジトリをモックします。

    .Domain は、モックされたリポジトリを使用してドメイン オブジェクトをテストします

すべてAutoFacと一緒に配線されています

于 2010-05-26T13:16:40.513 に答える