TL;DR
- 境界づけられたコンテキストは、それぞれ独自のデータストアとスキーマを持ち、他のシステムはそのデータに直接アクセスしない。目標は、各コンテキストが独立して進化できるようにすることである。
- BI システムのように複数のコンテキストのデータが必要な場合は、イベントを購読するなどしてデータをコピーする。
内容
第12章 Persistenceのガイドラインの 1 つである。このガイドラインは、次の 2 つを表している。
- 境界づけられたコンテキストは、それぞれ独自のデータストアと関連するスキーマを所有する。これらは、他のコンテキストと調整せずにいつでも変更できる
- 他のシステムは、境界づけられたコンテキストが所有するデータに直接アクセスできない。代わりに、そのコンテキストのパブリック API を使うか、データストアのコピーを使う
目標は、各コンテキストを切り離し、独立して進化できるようにすることである。たとえばシステム A がシステム B のデータストアにアクセスしているなら、コードベースが完全に分かれていても、データを共有している時点で 2 つのシステムは結合していると見なせる。
どう切り離すか
極端な例を 2 つ考える。物理的に極端な例では、各コンテキストが物理的に別のデータベースを持ち、他のコンテキストとは完全に分けてデプロイされる。論理的に極端な例では、すべてのコンテキストのデータを 1 つの物理データベースに格納し、名前空間などを使って各コンテキストのデータを論理的に分ける。
複数ドメインのデータを扱う
ビジネスインテリジェンス（BI）システムは、複数のコンテキストのデータにアクセスする必要がある。そのまま実装すると、「他のシステムは所有するデータに直接アクセスできない」というガイドラインに違反する。回避策は次の 2 つである。
- BI を 1 つのドメインとして扱う
- 他のコンテキストが持つデータをコピーする
データをコピーする考え方自体は、OLTP と OLAP の区別のように昔からある。コピーの方法には次の 2 つがある。
- イベントを購読する: 他のシステムが発行するイベントを購読し、対応するレコードを自分のデータストアに挿入する。BI のコンテキストを単なる別のドメインとして扱えるので、設計で特別扱いする必要がない
- 元のシステムからコピーする: 最初の実装は簡単だが、元のスキーマの変更に追従させる必要があり、保守しにくい
なお、BI システムでは、これまで見てきたような厳密なドメインモデルを定義するより、アドホックなクエリや多様なアクセス手段を効率よく扱える多次元データベース（キューブ）を作るほうが重要である。
キーワード
自分の理解
「独自のデータストア」は、論理的でも物理的でもよいと理解した。物理的ならデータベースそのもの、論理的なら ORM のモデルのように、作られるタイミングが別のデータである。たとえば在庫管理システムと注文管理システムの「商品」がそうで、在庫からは削除しても、注文の履歴としては持ち続けたい。
物理的に極端な例はマイクロサービス、論理的に極端な例はモノリスに近いのではないかと考えているが、まだ確信はない。