ブルーブックのいくつかの章を読み始め、レッドブック (Implementing Domain Driven Design) の最初の 3 つの章を読みました。2 つの質問があります。
(1) サブドメインは複数の境界付きコンテキストを持つことができますか? 私は特に、Implementing Domain Driven Design book の例を見ています。ここでは、サブドメインの予測が在庫と結合/重複しています。(本を読んでいない場合は申し訳ありませんが、2 つの境界付けられたコンテキストの間に強い重複があるという考えです)。
(2) プロジェクト ソリューション構造を整理するにはどうすればよいですか (私は .net を使用しています)、私が参照できる実際のプロジェクトの例はありますか? subdomain、core-domain、generic-domain というフォルダーを作成し、その下にモジュールを指定する必要がありますか? タマネギ/六角形の層が配置されていることを示すように、構造を定義する最善の方法に苦労しています。
前もって感謝します。
はい。ドメインは複数のサブドメインから構成され (十分に複雑な場合)、それぞれが実際には境界付けられたコンテキストのグループです。ドメイン自体は、アプリの観点からは、境界付けられたコンテキスト (BC) と見なすことができます。BC は、固有のモデルが含まれていることを意味するのではなく、ビジネス コンセプトの特定の表現を意味します。したがって、複数の BC で Book 定義を使用できますが、各 BC では定義がわずかに異なり、完全な詳細から単なる ID までさまざまです。したがって、在庫からの本は、たとえば販売からの本とは異なります。BC が概念をどのように理解するかが重要です。結果のモデルは、別の BC のモデルと同じ名前を持つことができますが、その BC でのみ有効です。しかし、それが名前空間の目的です。
そのためのレシピはありません。誰もが自分に合っていると思う方法でプロジェクトを構成します。ただし、ほとんどの場合、少なくとも 1 つのドメイン プロジェクトと、UI、持続性、インフラストラクチャ プロジェクトを用意します。最適な構造はアプリと開発者の考え方に依存すると思いますので、私のやり方があなたにとって最適な方法ではないかもしれません。簡単に言えば、自分にとって意味のあるアプリを構成します。