エンティティと値オブジェクトの名前空間を作成する必要がありますか？

Question

私はDDD原則を使用してアプリケーションを構築しています。私は今、私のアプリケーションの中核となる名前空間構造について考えています。以下の考え方を参照してください：

Company.Application.Core.Entities 
Company.Application.Core.ValueObjects 

しかし、私はGitHb上でアプリケーションの一例を見つけることができません。これはこの規則に従います。この命名規則に従わない特定の理由はありますか？

私もエンティティの基本クラスを持っているCompany.Application.Core.Entities.EntityをIEと値オブジェクトの基本クラスはCompany.Application.Core.ValueObjects.ValueObject

、すなわち代替オプションは、内のすべての値オブジェクトとエンティティを置くことです。あなたのための別の名前空間を使用してCompany.Application.Core

Answer 1

あなたのアプローチはうまくいきますが、そのような構成は、DDDビルディングブロックに焦点を当てたコードについての話であり、ドメインの内在する機能に関するものではありません。 DDDでは、ドメインに関する重要なことを示したいので、技術の問題はもう重要な懸案事項ではありません。

私は次の名前空間を作成示唆

：ここ

YourCompany.YourApplicationName.YourParticularBoundedContextName.Application 

あなたはすなわち、アプリケーションサービスのすべてのアプリケーションスコープのビルディングブロックを保つことができるとDTOのアプリケーションサービスにパラメータを転送し、そこからデータを返すために使用されています。

YourCompany.YourApplicationName.YourParticularBoundedContextName.Domain 

これは、ドメインスコープビルディングブロックのサブネームスペースを作成する名前空間です。 C＃で、それがある場合

YourCompany.YourApplicationName.YourParticularBoundedContextName.Domain.AggregateName 

各集計が などを、集約ルートクラスが存在した独自の名前空間を持つエンティティと、必要な場合のVOは、この集約、リポジトリのインターフェース、集約工場で内部的に使用私は知りません可能ですが、JavaではAggregateに別のパッケージ（ネームスペース）を持たせることのもう1つの利点があります - Aggregate Rootクラスをパブリックにすることができ、パッケージスコープとして内部的に使用される他のエンティティとVOをすべてパッケージの外部）。保護者があるので、あなたは、誰も破ることはできないことを、あなたの集計のためのパブリックAPIを構築し、この方法：コンパイラ:)

YourCompany.YourApplicationName.YourParticularBoundedContextName.Infrastructure 

ここでは、リポジトリの実装のための場所です（集約対応のサブ名前空間内の各）

基本クラスに保存することができます。

YourCompany.YourApplicationName.Domain 

、あなたが別のアプリケーションで再利用しようとすることができるようにも別のプロジェクトに保管します。

利点は何ですか？コードを使って作業するときは、技術的側面ではなく機能やドメインに焦点を当てています。 「このプロセスフローはどのように見えるのですか」などの問題に対処する必要があります。「すべてのエンティティとVOを一度に見たい」というコード構造がサポートされています。エンティティ（実際に部品を集約する）とVO（集約パーツ）を別々の名前空間に分けて、何が何を扱っているかについての情報を失った。泥の大きな球で簡単に終わることができます。再利用してはならないものを再利用するからです。

https://github.com/BottegaIT/ddd-leaven-v2 この方法でパッケージ化されたJavaのサンプルプロジェクトです。多分あなたを助けるでしょう。

もう1つの例は、DaughについてのVaughn Vernonの書籍のサンプルである https://github.com/VaughnVernon/IDDD_Samples です。

役立ち記事もあります： http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html

Answer 2

.Entitiesと.ValueObjectsが特に一般的な選択肢ではない場合でも、（データベーステーブルなどにマップされる）エンティティタイプと（アプリケーションのクライアントレイヤーとサーバーレイヤー間でデータを渡すために使用される）DTOタイプはかなり標準的な方法です。私はあなたがそれらを一貫して使用する限り、あまりにも心配する価値があるとは思わない。