問題タブ [bounded-contexts]

さまざまな境界付けられたコンテキストを Windows Service Bus と統合していますが、いくつか質問があります。

1) 他の境界付けられたコンテキストで重複を検出する方法は? 最後に処理されたメッセージ シーケンスを保存しますか? イベントを再起動HandleEvent(OrderPlaced orderPlaced, bool isReplay)して、最初の同期のために将来的に本番環境に組み込まれる新しい境界付けられたコンテキストを再同期できるようにする機能が必要です。

2) コンテキスト間メッセージ バスの場合、境界付けられたコンテキストごとにトピックを使用しますか (また、境界付けられたコンテキストをグループ化する名前空間を持ちますか)? それとも、名前空間ごとに 1 つの境界付けられたコンテキストですか?

3) メッセージ バスのドキュメントには、メッセージが順不同で到着する可能性があると記載されています。メッセージ 6 と 8 が受信されたが、7 が受信されなかった場合はどうなるでしょうか? 指定された時間待ってから続行しますか? 自己修復を許可するには?

4) 上記はほぼすべての DDD プロジェクトでかなり一般的だと思いますが、コマンド/応答プロトコルを含むメッセージングを処理して、外部の境界付けられたコンテキストから以前のイベントの同期を要求するライブラリはありますか?

最も優れた DDD の概念の 1 つは、アプリケーション内の個別のコンテキストの機能です。しかし、どうすればすべてを一緒に機能させることができるかについて混乱しています。

まず、あることは他のこととは関係がないことを知っています。しかし、私の質問はまさにインフラストラクチャ/ORM の部分に関するものです。

たとえば、Procedure (医療処置) というドメイン オブジェクトがあります。Registrationのコンテキストでは、重要なのはCodeとNameだけです。しかし、Procedure Management Contextには、このコンテキスト固有に属するPriceのような他のフィールドがたくさんあります。

EF Code First を使用して、異なるプロパティを持つ (異なるコンテキストで) 同じ名前の 2 つのエンティティを作成するにはどうすればよいですか? 基本的に、すべてのフィールドを同じテーブルに保存したいのですが、1 つのコンテキストでは 2 つのフィールドのみを取得し、他のコンテキストではすべてのフィールドを取得します。どうすればこれを達成できますか？

個人的なプロジェクトでドメイン駆動設計を実践しようとしています。Bounded Contexts で分割しようとしているサンプル ドメインがあります。

方法を知っているとほぼ確信していましたが、それらを定義した後、それらについて確信が持てなくなりました。

それらが適切に定義されていることをどのように知ることができますか? 私が間違っているかどうかをどのように判断できますか？

私は、DDD と境界コンテキストの使用にどのようにアプローチするかを理解しようとしています。

私の質問を説明するために、例を考え出そうとしました。（迅速にするために貧血クラスを使用しています）。

私は、異なる境界付けられたコンテキスト内でドメイン オブジェクトを分離する方法を計画しようとしています。

従業員になり得るドメイン オブジェクトについて考えました。

人事部と財務部という 2 つの境界付けられたコンテキストがあるとします。

一般に、財務部門は、人事部門よりも従業員に関するより多くの情報を必要とします。人事部は、従業員の銀行の詳細、国民保険番号、または契約時間に関する情報を必要としません。(一部のビジネスでは、これは完全に真実ではないかもしれませんが、例ではこれを想定してみましょう)。

したがって、2 つの異なるコンテキストでは、従業員に必要な動作/相互作用が異なります。

人事部門。

財務部。

この例では、HR コンテキストの Employee オブジェクトを制限して、必要な動作のみを行い、Finance コンテキストには拡張動作を持たせるにはどうすればよいでしょうか。

アプリケーションが複数のコンテキストに分割され、そのすべてが Employee に関連付けられたカスタム動作を持っている場合、Employee オブジェクトをどのようにモデル化すればよいでしょうか。

コンテキスト マップを作成するさまざまな方法を調べましたが、共有カーネルが有望に思えますが、それはすべてのコンテキストが Employee Domain オブジェクトに関連付けられたすべての動作を共有することを意味します。

それぞれの文脈は限られていると思います。

ヘルプ！

大規模なプロジェクトの一部である MVC データ メンテナンス アプリケーションを作成しています。ドメイン駆動設計の DDD を使用しようとしています。SO には、これに関する他の質問が既にあります。たとえば、here、here、およびhereです。しかし、彼らは私の質問に完全には答えていません。

データベースには 755 個のテーブルがあるため、データ層にも境界付けられたコンテキストがあります。そのため、ビジネス、役割、製品、顧客などの境界付けられたコンテキストを作成しました。

私たちが抱えている問題は、MVC アプリケーションには、最終的に複数の境界付けられたコンテキストにまたがる ViewModel を使用する「初期設定」のビューがあることです ( Entity Framework 6 の IUnitOfWork パターンを使用)。したがって、そのビューはビジネス コンテキストとロール コンテキストに書き込む必要があります。

ドメイン モデルには、1つBusinessのモデルAddressと 1 つのモデルと、より大きな pobject グラフ内の他のいくつかのモデルがあります。

ViewModelは、これら 2 つのドメイン モデルとその他のドメイン モデルをフラット化して単純化したモデルです。

この ViewModel は、 Automapperで行っているドメイン モデルにマップする必要があります。

コントローラーにドメイン サービスが注入されます。

問題:

1. サービスはについて知ることができないInitialSetupViewModelので、何をサービスに渡す必要がありますか?

2. BusinessDbContextサービスはおよびについて認識している必要がありRolesDbContextます。そのため、両方で SaveChanges() を呼び出す必要があります。これは、単一の IUnitOfWork を持つという目的に反します。ビジネス エンティティとロール エンティティの両方を含む別の UnitOfWork を作成する必要がありますか?

この MVC ビューを機能させるためだけに、これら 2 つの IUnitOfWorks を 1 つに結合することは正当化できないと思います。しかし、解決策は何ですか？

ありがとうございました！

エンタープライズ アプリケーションでの EF の使用に関する Julie Lerman のビデオを見たことがあります。今、私は「Bounded Contexts」と彼女がそのシリーズで教えた他のものを使用して Web サイトを開発しています。

問題は、「ビジネス層」内から境界付けられたコンテキスト (BC) を使用する方法がわからないことです。より明確にするために: BL は、どの特定の BC を使用する必要があるかをどのように知る必要がありますか。

UI がビジネス層から製品のリストを要求するとします。BL には、製品のリストを返すメソッドがあります: GetAll(). このメソッドは、UI のどの部分 (サイト管理者、モデレーター、またはパブリック ユーザー) が製品のリストを要求したかを知りません。各ユーザー/シナリオには独自の境界付けられたコンテキストがあるため、その関連するコンテキストを使用してリストを取得する必要があります。BL は適切な BC をどのように選択する必要がありますか?

さらに、UI レイヤーがデータ レイヤーと対話することは望ましくありません。

これはどのように行うことができますか？

私は DDD と境界付けられたコンテキストについて読んできましたが、考えが間違っていると思います。最初は、サブドメインと境界付けられたコンテキストのアイデアが好きで、次のように理解していました。開発するソフトウェアがありますが、一度に攻撃するのは多すぎるため、論理的な断片に分割して、一度に開発します。私たちが解決するもう 1 つの問題は、ユビキタス言語のあいまいさです。

これにより、境界付けられたコンテキストを基本的には、アプリケーションの特定の部分に関連するコードをグループ化してバインドする単なるフォルダーと考えるようになりました。このコードは、次のようなものから構成されていると信じていました

• リポジトリとサービスの抽象化を含む、その境界付けられたコンテキストのドメイン モデル
• その境界付けられたコンテキストのインフラストラクチャ層、リポジトリの実装など

もちろん、ドメイン モデルとインフラストラクチャは、境界のあるコンテキスト内で適切に分離されています。

しかし、さらに読むと、それぞれの境界付けられたコンテキストは、それ自体が完全なアプリケーションであるように見えます。たとえば、境界付けられたコンテキストごとに独自のアプリケーション層があるように見えることがあります。

これは私を混乱させました。なぜなら、大量のアプリケーションの開発を終わらせたくない場合があるからです。アプリケーションの境界付けられたコンテキスト区分は、1 つのアプリを構築することになっていました。統合されるアプリは多くありません。

@MikeSWがOPによって提示された両方のアプローチが有効であると言っているこの質問のようです。私が求めているのは、3番目の構造についてです:

少なくとも、私が見たすべてのアプリケーションでは、これははるかに理にかなっていると思います。いくつかのプレゼンテーションを備えた複数のアプリではなく、1 つのアプリが必要ですが、ドメインを壊して、「ユビキタス言語の境界」などの利点を得ることができるようにしたいと考えています。

では、境界付けられたコンテキストは完全なアプリケーションですか? または、私が理解し、より便利だと感じたように、境界付けられたコンテキストを使用できますか? 私のアプローチに問題はありますか？