問題タブ [bounded-contexts]

私たちのプロジェクトでは、境界付けられたコンテキストのイデオロギーを適用しようとしていますが、明らかにパフォーマンスの問題に直面しています。たとえば、システム内のユーザーを表すためのさまざまなクラス (さまざまなコンテキスト) があります:Personコア ドメインのコンテキストとUserセキュリティ コンテキストです。したがって、集計ごとに 2 つの異なるリポジトリがありますが、それらは DB で同じテーブルを使用しており、同じデータにアクセスすることもあります。

この場合、db ラウンドトリップを最小限に抑える一般的な解決策はありますか? それを扱うORMはありますか、それともキャッシングシステムを自分でコーディングする必要がありますか?

upd:データベースはレガシー アプリのものであり、「そのまま」使用する必要があります。

ドメイン内にいくつかの異なる境界コンテキストがあります。CRUD 操作の検証は、各 Bounded Context に組み込まれています。

たとえば、作成者がグループ リーダーである場合にのみ、GAME というエンティティを作成できます。

この例では、境界付けられたコンテキスト (BC) が 2 つあります。1 つはGame BCで、もう1 つはUser BCです。この問題を解決するには、ゲーム BCで、ゲームの作成に進む前に、ユーザー BCに対してIsGroupLeader()などのドメイン サービス呼び出しを行う必要があります。

このタイプの通信は、DDD によって推奨されているとは思いません。Game BCにもUser エンティティを含めることができますが、同じUser エンティティが別の BC の別のコンテキストで異なる方法で使用されているため、使用したくありません。

私の質問は次のとおりです。

1. Game BCがUser BCにイベントを送信してUser のステータスを尋ねる場合、ドメイン イベントを使用する必要がありますか? このアプローチでは、 IsGroupLeader のような同期呼び出しを行わず、is_group_leaderというイベントを呼び出します。次に、ゲーム BC は、ユーザー BC がイベントを処理してステータスを返すまで待機する必要があります。ゲーム BC は、ユーザー BC がイベントを処理した後でのみ、ゲーム エンティティを作成します。

2. CQRS は私の問題の解決策ですか?

どんなアイデアでも大歓迎です。

DDD アーキテクチャを利用するようにリファクタリングする予定の WinForms アプリケーションがあります。まず、私はアーキテクチャ自体に頭を悩ませようとしています。Evans の本と Vernon の本を持っていますが、アプリケーションですぐに直面する 3 つのシナリオに苦労していることに気づきました。概念設計プロセスで考えすぎたり、厳密すぎたりするのではないかと心配しています。

1.) DDD に関する Pluralsight チュートリアル内で提供された例を利用して、スピーカーは、さまざまな境界付けられたコンテキストを独自のソリューションで表す必要があることを指摘しました。ただし、サービス指向ではない winforms アプリがある場合 (これは最終的に変更され、この質問の多くは意味がなくなります)、これは実行可能ではないようです。したがって、相互依存関係がないことに注意して、これらを異なるプロジェクト/名前空間に分離するという前提で運用しています。これはそれについて考える正しい方法ですか、それとも明らかな何かが欠けていますか?

2.) 異なる境界付けられたコンテキストの別々のプレゼンテーション レイヤーに属する他のモジュール/ウィンドウを起動するナビゲーション UI があります。ERP アプリケーションを起動したときに最初に開くウィンドウを考えてみてください。これは特定の BC 内にきれいに収まらないため、このようなものを適切に実装するにはどうすればよいでしょうか。これは共有カーネル内に収まる必要がありますか?

3.) ジョブ管理境界コンテキストと評価/原価計算境界コンテキストがあります。ジョブが作成されたときにその詳細が評価されるのは、ビジネス プロセスの一部です。これには独自の UI などがありますが、このプレゼンテーションがまだジョブ管理のコンテキスト内に適切に収まっていることは非常に良いと思います。ただし、これらの詳細の実際の評価プロセスは絶対にすべきではありません。bc は互いに分離されているため、Rating/Costing コンテキストと通信する方法が完全にはわかりません。メッセージングを行うことができることはわかっていますが、非分散アプリにとってはやり過ぎのようです。各 BC は、ある種の API を自己ホストすることもできますが、これはやり過ぎのように思えますが、これにより、後で分散アーキテクチャに移行するためのチームの準備が整います。ついに、私の最後のアイデアは、一種のイベントストアであるある種の共有依存関係を持つことです。これがドメイン イベントと同じかどうかはわかりません。ドメイン イベントはそれ自体に別の懸念があるようです。では、これは共有カーネルまたは他のタイプのソリューションに該当するということですか?

前もって感謝します。

私は、100 を超えるモジュールと、データベース内のほぼ 500 のテーブルを含む非常に大規模なアプリケーションに取り組んでいます。Entity Framework 4.2 Code First を使用して、このアプリケーションを WPF/WCF に変換しています。私たちのデータベースは SQL Anywhere 11 です。データベースのサイズのため、 Julie Lerman によるhttp://msdn.microsoft.com/en-us/magazine/jj883952.aspxで説明されているように、Bounded DbContexts と同様のアプローチを使用しています。 . 各モジュールは独自の DbContext を作成し、必要なデータベースのサブセットのみをモデル化します。

しかし、DbContext の作成方法に深刻な問題が発生しました。私たちのモジュールは自己完結型ではなく、自己完結型でもありません。一部のモジュールには、他の複数のモジュールから呼び出される操作が含まれています。その場合、呼び出しモジュールによって開始されたトランザクションに参加する必要があります。(また、アーキテクチャ上の理由から、DTC はオプションではありません。) 古い ADO アーキテクチャでは、トランザクションをサポートするためにモジュールからモジュールへオープン接続を渡すことに問題はありませんでした。

私はさまざまな DbContext コンストラクターのオーバーロードを調べ、EntityConnection と StoreConnection からトランザクションを管理しようとしましたが、私が知る限り、ModuleA がトランザクションを開始し、ModuleB で関数を呼び出して、 ModuleB の DbContext がトランザクションに参加します。

それは次の 2 つの簡単なことに帰着します。

ケース 1. DbContextA の EntityConnection を使用して DbContextB を構築すると、DbContextB は独自のモデル メタデータを使用して構築されません。DbContextA のメタデータを再利用します。コンテキストには異なる DbSet のコレクションがあるため、ModuleB のクエリはすべて失敗します。(エンティティ タイプは現在のコンテキストの一部ではありません。)

ケース 2. ModuleA の StoreConnection で DbContextB を構築すると、DbContextB は EntityConnection レベルで StoreConnection の開いているトランザクションを認識しないため、ModuleB が SaveChanges() を呼び出すと、EF は新しいトランザクションを開始しようとします。実際、データベース接続には開いているトランザクションがあるため、これによりデータベース例外が生成されます。(接続は並列トランザクションをサポートしていません。)

1) ケース 1 で DbContextB に独自のモデルを強制的に構築させる方法、または 2) ケース 2 で DbContextB の ObjectContext を取得して StoreConnection のトランザクション状態を尊重させる方法はありますか?

(ちなみに、私は EF6 アルファ版で心強いものを見ましたが、テストした後、唯一の違いは、開いている接続で DbContextB を作成できることでした。それでも、上記の 2 つの問題は依然として存在します。)

このコードサンプルを見つけました。

https://code.google.com/p/ddd-cqrs-sample/

非常に完成度が高く、よく整理されているようです。「フレームワーク」ではなく、物事を行うための非常にきめ細かく明示的な方法を備えた単なるサンプル プロジェクトです。しかし、不完全です。そして、これはいくつかの疑問をもたらします。

彼らは質問に答えるのが上手です。https://groups.google.com/forum/#!forum/ddd-cqrs-sampleで Google グループを確認してください。

わかった。SALES BC に Client があり、CRM BC に Customer/Leads があるということです。私たちは皆、同じ「人」を指していることに同意すると思います。販売目標到達プロセスで、その人が見込み客として始まり、何かを購入して顧客になることで顧客になるとしましょう。

私の質問は、なぜ彼らは同じ「人」の3つの別々の表現を持っているのですか? 「共有カーネル集合体」のようなものではないでしょうか? そのようなものが存在するかどうかはわかりません。データベース クライアント/顧客/リードに同じ「もの」の 3 つのテーブルがあるのはちょっと気になります。さらに、この例では、BC 間の通信方法が明確ではありません (CRM は実装されていません)。私は彼らのドキュメントを読みましたが、それに関する貴重な手がかりは見つかりませんでした。

そのプロセスはどのようになりますか？注文を発送するために、このリード/顧客/クライアントに住所を追加する必要があるとしましょう。あなたならどちらを選びますか？Shipping BC の ShippingAddress だと思いますか。を指しているIDで？お客様？クライアント？住所を顧客に直接追加する必要がありますか? 例えばダイレクトメールの場合、配送とは関係ないので？

境界付けられたコンテキストについてよく検索しましたが、それがドメイン駆動設計のパターンであり、データベース コンテキストを使用して大きなモデルを小さなモデルに分割するためのものであることはわかっていますが、少し混乱します。実際、私はそれが正確に何をするのかわかりませんか？このパターンを使用する利点は何ですか? このパターン
を理解するのを手伝ってください。

Entity Framework Code First で複数のデータベース コンテキストを実装するのに苦労しています。写真に示すように、3 つのコンテキスト (すべてのエンティティ、会議に関連するエンティティ、およびユーザー プロファイルに関連するエンティティ) を既に実装しています。

Fluent API は、エンティティ マッピングに使用されます。たとえば、これは ConferenceContext に使用されるコードです。

下の図に示すようなコンテキストを作成するのを手伝ってくれる人はいますか。

ORM が取り込まれているドメイン プロジェクトをセットアップしました。ドメインには、それぞれ独自のルート オブジェクトを持つさまざまな集約が含まれています。私の質問は、集約境界を越えるプロパティをどのように扱うべきですか?

• これらのプロパティは境界を単純に無視して、境界付けられたコンテキスト A のドメイン オブジェクトがコンテキスト B のオブジェクトへの参照を持つようにする必要がありますか?
• または、コンテキスト A から B への直接リンクはなく、コンテキスト A のオブジェクトには、B 集約ルートを介して B からドメイン オブジェクトを取得するために使用できる「int ContextBId」プロパティがありますか?
• または ...

例:
コンテキスト A = ユーザー
コンテキスト B = ゲーム

Usersコンテキスト内には object がありますUserOwnedGames。Userこのオブジェクトには、同じUsersコンテキスト内のオブジェクトへの参照であるプロパティがあります。オブジェクトには、Game明らかにユーザーではなくGamesコンテキスト内にある へのプロパティもあります。

この関係はどのように見えるでしょうか (またはあるべきでしょうか?)。データベース (つまり 2 つの外部キー) では明らかですが、コードはどのように見えるでしょうか?