私は現在 DDD について読んでいますが、この質問に対する答えを見つけることができませんでした。複数の境界付けられたコンテキストを持つ大規模なアプリケーションがある場合、私が知る限り、各 BC は個別のアプリケーションであるため実装する必要があります。したがって、各 BC には独自の UI とイベント ストレージがあるという結論に達するのは論理的です。いくつかの記事 (CQRS について) によると、イベント ストレージは単一の信頼できる情報源であるため、以前は単一のイベント ストレージしかないと考えていました。これらのステートメントの唯一の問題は、コンテキストが不足しているということです。では、イベント ストレージは、単一の境界付けられたコンテキストまたはアプリケーション全体における唯一の信頼できる情報源でしょうか?
質問する
1340 次
1 に答える
6
"Is an ES the single source of truth in a bounded context or in entire application?"
Bounded Context は最も簡単な説明ではアプリケーションであるため、システムを意味していたと思います。
"If we have a large application with multiple bounded contexts"
同じモデル内に複数の境界付けられたコンテキストを持つことはできません。境界付きコンテキスト制限モデル。したがって、用語bounded contextを変更する必要subdomainがあり、それは正しいでしょう。
とにかくあなたの質問に答えます。場合によります。
システム全体の単一イベント ストア
長所
- 1 か所で管理
- CorrelationIDで関連イベントが見やすい
- 一部のソフトウェアでは、サービス検出が不要です。すべてのサービス (アプリケーション) は、単一の ES を介して統合できます (データ ストレージではなく、真の ES について話しています)。
- 必要な CPU/メモリが少ない
短所
- 単一障害点 (もちろん、そのような状況を回避するために拡張できます)
- サービスを結合しています (マイクロサービスのルールを破っています)
- システムの存続期間中は ES を変更しないことが義務付けられています
アプリケーションごとに 1 つのイベント ストア
長所
- 単一障害点なし
- アプリケーションでデプロイ
- サービス間の結合はありません。自律性の向上
- アプリケーションが無効になる場合は、ES を無効にすることができます
- 新しいサービスは、新しいバージョンまたは別の ES でも動作可能
短所
- 注意して監視する追加のデータベース
- 消費される CPU/RAM の増加
- 複数の ES に分割されているため、correlationID の管理が困難
- サービスの検出が必要です。複数の ES にサブスクライブする場合、または追加のメッセージ キューが必要な場合
于 2016-01-09T11:38:30.217 に答える