境界づけられたコンテキストは独自のデータストアを所有する
具体的には、以下の 2 つを表す
これらの情報は、他の境界づけられたコンテキストと調整することなくいつでも変更できる
独自のデータストア
論理的でも物理的でも良い radish-miyazaki.icon
物理的: データベース
論理的: ORM における Modelのように、生成されるタイミングが別のデータ e.g. 在庫管理システム と 注文管理システム における「商品」
在庫からは削除しても、履歴として持ったままにしておきたい
代わりに、境界づけられたコンテキストのパブリック API を使用するか、データストアの何らかのコピーを使用すべき
e.g. レポーティングシステム や ビジネスアナリティクスシステム
e.g. システム A がシステム B のデータストアにアクセスする
コードベース が完全に独立しても、データを共有していると 2 つのシステムは結合していると見なせる 具体的にどう切り離するか
極端なケースを考える
物理的に極端な例
各境界づけられたコンテキストがそれぞれ物理的に異なるデータベースを持ち、他のコンテキストとは完全に分離してデプロイされる
論理的に極端な例
すべてのコンテキストのデータを 1 つの物理的なデータベースとして格納する
名前空間 などを活用して、各コンテキストのデータを論理的に分離する 複数ドメインのデータを扱う
ビジネスインテリジェンス（BI） システムについて考える このようなシステムでは、複数のコンテキストからデータにアクセスする必要がある
そのまま実装してしまうと、以下のガイドラインに違反する
回避策
1. 「ビジネスインテリジェンス」をドメインとして扱う
どうコピーするか
1. 他のシステムから発行されるイベントをサブスクライブし、そのイベントに対応するレコードを自身のデータストアに挿入する
https://scrapbox.io/files/66b72a729b32b9001d21ef88.png
BI コンテキストは単なる別の ドメイン として扱えるため、設計において特別視する必要がない 2. 元となるシステムから BI システムにデータをコピーする
最初の実装は簡単だが、元となるスキーマの変更に追従させる必要があり、保守性 が低い