問題タブ [bounded-contexts]

シナリオの分離された境界コンテキストの統合を理解しようとしています。

1 つのコンテキストがDocument Core Bounded Context (BC)であり、 Authorを持つDocument Entity を持っているとします。ユーザー、グループ、およびロールを独自のコンテキストに分離するDDDの実装ブックのように、 IdentityAccessContext BCを使用することは理にかなっています。

発生している問題は、たとえば 100 以上のドキュメントのリストをフェッチすることを検討する場合です。

ドキュメント コアBCには、ドキュメントの作成者をマークする独自のエンティティがあるとします。

そして、アイデンティティBCには関連情報を持つユーザーがいます。

List of Documentsを取得する場合、 IdentityAccess BCからの情報はどのように取得してDocument Authorに表示する必要がありますか (フルネームなど)?

いくつかの選択肢があるようです：

1. おそらく、両方のテーブルからデータを取得する腐敗防止レイヤーでしょうか?
2. 2 つの BCでユーザーの氏名を複製しますか?

#1 では 2 つの BC からデータを (あるレベルで) 結合する必要があり、#2 ではユーザー名を変更するときに複数の BC を更新する必要がある可能性があるため、どちらも適切ではありません。

これについて何ができるでしょうか？(問題がある場合は、C#、MVC、NHibernate を使用します) オブジェクトのリストを明確に取得し、後で作成者の名前や追加データなどを後で取得することは現実的ではありません。

ただし、 BC統合を見ると、本 RPC、ドメイン イベント、および RESTful サービス統合で言及されている 3 つのオプションを考えると、アプリケーションが MVC であるこの場合、少なくとも後者の 2 つは意味がなく、直接2 つの BC はクラス ライブラリとして使用され、どちらも同じデータベースを使用します。ユーザー情報の更新は、Identity BC のアプリケーション サービスを介して MVC から直接行うことができます。データベースと BC は必要に応じて変更できます。

Shipping ContextとBilling Contextという 2 つの境界付けられたコンテキストがあるとします。これらの各コンテキストは、顧客について知る必要があります。

CustomerTblデータ レベルでは、顧客はデータベース内のテーブルによって表されます。このテーブルは、顧客を説明するために必要なすべての列で構成されています。

列CustomerTbl(簡略化):

• Name
• PhysicalAddress
• PaymentMethod

Shipping Contextは と に関係し、NameBillingコンテキストはと に関係します。PhysicalAddressNamePaymentMethod

Shipping Contextでは、集計をモデル化しましたRecipient。

• Recipientと のプロパティ/値オブジェクトが追加されましNameたPhysicalAddress

請求コンテキストでは、集計をモデル化しましたPayer。

• Payerと のプロパティ/値オブジェクトがNameありますPaymentMethod

RecipientとPayer集約の両方は、コンテキスト境界によって完全に分離されています。また、独自のリポジトリもあります。

質問:

1. 同じ「データベース テーブル」を使用して、複数の集計 (それらが別々の境界付けられたコンテキストにある場合) を持つことは許容されますか?

2. 顧客データは、より多くの限定されたコンテキストで必要になる可能性があります。これは、境界付けられたコンテキストごとに多くの集約、リポジトリ、およびファクトリの実装を意味するのではないでしょうか? コードにはある程度の冗長性があります。これは保守性に影響しませんか？

3. 集約間でプロパティを共有することは許容されますか? 例として、顧客のNameプロパティがあります。これは冗長な検証コードを意味しますか?

ドメイン駆動設計 境界のあるコンテキストを分離するためにイベントを渡す

MVC のユーザー アクションは、リモート (同じ LAN) イベント ハンドラーに渡されるイベントを生成する必要があります。

私がテストしたこと：

1. MVC: サービス呼び出しを起動して忘れる (非同期) ->
2. (IIS がホスト) データを収集してメッセージを入力する WCF ->
3. EasyNetQ/RabbitMQ ServiceBus 経由で送信 ->
4. イベントは、イベントとそのデータを処理するサブスクライバー (WCF サービス エンドポイントから初期化された DI コンテナーを使用) によって消費されます。

MVC側でループすることでサービスがかなり速く呼び出された場合にどのように機能するかを確認するためにいくつかのテストを行いました

MessageQueue 部分は、キューに送信され、同じ秒内にサブスクライバーによって受信されるタイムスタンプに基づいて高速です。WCF サービス呼び出しのループは非常に低速です。それらをループするのに数秒かかります。wsHttpBinding から netTcpBinding に切り替えて、WCF で serviceThrottling をいじってみました。

WCF は必須ではありませんが、別のイベント処理プロジェクト (パブリッシャー側) が有益であり、MVC アプリの別の場所に物理的に配置できるようです (負荷の軽減など)。このような状況で WCF はもっともらしいですか、または Windows サービスまたは他の自己ホスト型のコンソール アプリなどを使用するか、MVC のスレッドを使用してイベント データを生成する可能性がありますか、またはより良いシナリオがありますか? このタイプのイベント処理システムのベスト プラクティスは何ですか? 基本的に、エンド ユーザーが使用している UI の速度を落とさずにどこかで処理する必要があるため、イベント データを生成する何かがあれば有益であるように思われます。

私はドメイン駆動設計を始めたばかりで (職場にドメイン駆動設計の使用を勧める担当者がいます)、見たものは気に入っています。タマネギのアーキテクチャは理解しています。これは DDD と密接に関連していると思いますが、それが Bounded Contexts でどのように機能するかはわかりません。

マイクロソフトの紹介で、境界付けられたコンテキストの必要性を理解しています

DDD の概要

しかし、これらが個々のタマネギであるかどうかはわかりません。あたかも 1 つの大きなタマネギの中に他のタマネギが入っているかのように、いくつかの交差があるように見えますが、これを実装するのは難しいように思えます。

タマネギのアーキテクチャ パート 1

タマネギのアーキテクチャは境界付けられたコンテキストでどのように機能しますか?

Eric Evans の DDD: Tackling Complexity in the Heart of the Software を読んでいて、コンテキスト マップのセクションで、Evans はトランスレータを使用してそれらを統合する 2 つの境界付けられたコンテキスト (予約コンテキストとネットワーク トラバーサル サービス) の例を引用しました。

私の理解が正しければ、モデルを作成するときに、ドメインの概念的な境界を作成する境界付けられたコンテキストにすべてを入れます。私の質問は次のとおりです。

1. すべてが限定されたコンテキストにある場合、翻訳者はどこに配置する必要がありますか? Evans のサンプル ダイアグラムでは、翻訳者は両方の境界付けられたコンテキストの外 (中間) にあります。

2. ERP に取り組んでいるチームが 1 つあるとします。ERP を複数の境界付きコンテキストに配置するか、単一のコンテキストに配置するか。Evans のサンプルに基づいて、複数のチームが独自のモデルで作業できるように、境界付けられたコンテキストが考案されました。しかし、これは単一のチームであるため、統合が問題にならない単一のモデルでメリットが得られるのではないでしょうか? それとも私はこれを間違って理解しましたか？

3. 質問 2 の場合、境界付けられたコンテキストが複数ある場合、実装で、Payroll で使用する Accounting のクラスが必要な場合はどうなりますか? ここに翻訳者は必要ないと思いますが、必要なクラスを共有する方法がわかりません。別の境界付けられたコンテキストから必要なクラスを参照するだけで問題ありませんか?

4. 最後に、DDD のモジュールは境界付けられたコンテキストにどのように関連していますか?

ドメイン駆動型の設計アプローチを使用して Web アプリケーションに取り組んでいますが、DDD に適していないアプリケーションの側面がいくつかあります。たとえば、従業員の給与を一括更新する必要があります。一度に何百もの給与が更新されることが多いため、従業員エンティティ全体をロードして各従業員に保存するのは効率的ではありません。さらに、古い給与の記録や新しい給与の発効日の記録など、同時に実行する必要がある他のタスクがあります。したがって、このタイプの操作は、コア ドメインの境界付けられたコンテキストの外側にあると言えます。さらに、この操作は手続き上の観点からアプローチするのが最善であることを理解しています。それはすべて問題なく、良いことです。

たとえば、次の構造を使用しています。

• UI
• 応用
• モデル
• インフラストラクチャー

コア ドメインの境界付けられたコンテキストの外側にあるものについても、この構造に固執したいと思います。現時点での私の懸念は、主にインフラストラクチャ レイヤーに関するものです。もともと私はインフラストラクチャ内で以下を使用していました:

• リポジトリ
• ファインダー (個別読み取りモデル用)
• コマンド

アドホック読み取りクエリを Finders に配置し、アドホック コマンドを Commands に配置しました。これに関する問題は、一部の操作には一連のクエリとコマンドが必要であり、それらをすべて 1 つのユニットにグループ化する方が組織化されているように思われることです。リポジトリのようなものですが、ドメイン エンティティへのアクセスを提供する代わりに、特定の手順を構成する一連のクエリとコマンドをカプセル化します。

したがって、私が探しているのは、「コマンド」フォルダー/名前空間を、論理的に適合する一連のクエリ/コマンドをより適切に説明するものに変更するための命名規則に関する提案です。私が気付いていない名前/パターンが既にありますか?

アップデート：

現在、論理的に適合するこれらのクエリ/コマンドを説明する名前空間「手順」を検討しています。一方で、私が説明していることはストアド プロシージャに似ており、アプリケーションのこの部分が DDD アプローチではなく手続き型アプローチを使用していることを説明しているため、適切です。私の唯一の懸念は、この命名規則がストアド プロシージャの使用を暗示していることですが、そうではありません。