3

制限された各コンテキストには、コンテキスト間バスからメッセージをプルし、メモリ内バス（Reactive Extensions、またはhttps://github.com/flq/MemBus）を介してローカルにメッセージをディスパッチするイベントメッセージプロセッサがあります。

mycompany.accounts.infrastructure.messagesDDDの本では、やなどのプロジェクト内のモジュールにメッセージを配置することについて説明していますmycompany.ordering.infrastructure.messages。

複数のコンテキストを持つ私にとっての問題は、これらのメッセージを参照すると循環参照につながる可能性があります。

さまざまな制限付きコンテキストメッセージングコントラクトを整理する最善の方法：

  1. 各境界コンテキストには、他の境界コンテキストが参照できるように、そのコンテキストで可能なすべてのメッセージを含む個別のプロジェクトがありますか？

  2. または、コンテキスト間バスを経由するすべてのメッセージ用に個別の共有ライブラリを用意する方がよいでしょうか。

4

1 に答える 1

1

制限されたコンテキストごとに（少なくとも）2つのアセンブリを構築する同様の問題を解決します。

  1. コントラクト用の1つ（イベント、例外、共有識別子など...）
  2. 1つはエンティティの実装用です。

このように、異なる境界コンテキストの実装は、cicleなしで同じコントラクトを参照できます。

編集
命名規則に関しては、私は通常、境界のあるコンテキストの「従来の名前」にちなんでアセンブリに名前を付けます。たとえば、

  1. 契約のBankName.FinancialAdvisory
  2. 実装のためのBankName.FinancialAdvisory.POCO
  3. BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingNameは、特定の技術環境で使用するためにクラスを特殊化する必要がある場合に使用します。

ただし、POCOアセンブリ内では、ルート名前空間はコントラクトの名前空間と同じです（例：BankName.FinanicalAdvisory）。これは、技術的な懸念なしにビジネスルールをコードで表現するPOCOが、コントラクトの開発ライブサイクルが同じであるためです。逆に、技術専門分野を含むアセンブリは、アセンブリ名と同じルート名前空間（BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingNameなど）を使用します。

それでも、ドメインに関連するすべてのアセンブリは同じ名前空間構造を共有します。たとえば、名前空間 "Funds"がBankName.FinancialAdvisoryの下に存在する場合、POCOとORMOrOtherTechnologicalCouplingNameの両方にも存在します（もちろん、クラスが含まれている場合）。

于 2013-03-27T09:36:40.810 に答える