「Canonical Model」と「Bounded Context Model」は、どちらもシステム設計においてデータを扱う方法ですが、目的や使われ方が異なります。
Canonical Modelとは
目的: システム間の統合をシンプルにする
使い方: 異なるシステムやサービス間でデータをやり取りするときに、データを統一した「共通の形式」にするために使われます。各システムは、独自のデータ形式を持っていても、データ交換の際には共通の形式（Canonical Model）に変換します。これにより、システム同士のつながりをシンプルにし、保守性を向上させることができます。
例:
- Aシステムが「Product」、Bシステムが「Item」と呼んでいる商品情報を、共通の「ProductData」として統一して扱う。
- これにより、AシステムやBシステムは自分たちの形式から「ProductData」に変換するだけで、他のシステムとデータをやり取りできるようになります。
特徴: システム間の「共通言語」を作るようなイメージで、データの一貫性を重視します。
Bounded Context Modelとは
目的: 各ドメイン（業務領域）に最適化されたデータ設計をする
使い方: ドメイン駆動設計（Domain-Driven Design, DDD）の中で用いられる概念で、システム全体をいくつかの「文脈（コンテキスト）」に分け、それぞれのコンテキスト内で独自のデータモデルを定義します。各コンテキストは、自分の業務領域に合わせたデータ形式を使うので、他のコンテキストと異なるデータモデルを持っていても問題ありません。
例:
- 「注文管理」コンテキストでは、顧客情報を「Customer」と呼ぶが、「マーケティング」コンテキストでは、同じ顧客情報を「Lead」と呼ぶことができる。
- それぞれのコンテキストは、自分たちの業務に最適化された形でデータを扱うので、共通のフォーマットに無理に合わせる必要がありません。
特徴: 各コンテキストが独自のデータモデルを持ち、必要に応じてコンテキスト間で変換やマッピングを行います。システム全体を統一するのではなく、むしろそれぞれの領域の違いを尊重します。
違いのまとめ
| 項目 | Canonical Model | Bounded Context Model |
|---|---|---|
| 目的 | システム間の統合をシンプルにする | 各ドメインに最適化されたデータ設計 |
| データの扱い方 | システム全体で共通のデータ形式を使う | 各コンテキストごとに独自のデータモデルを定義 |
| 使われる場面 | システム統合（API連携やESBなど）での共通データモデルが必要な場合 | ドメイン駆動設計（DDD）のように、業務領域に分かれた設計が必要な場合 |
| 変換の考え方 | すべてのシステムが共通モデルに変換 | 必要に応じてコンテキスト間で変換やマッピング |
例えると:
- Canonical Modelは、異なる言語を話す人たちが「共通の言語（例えば英語）」を使って会話するようなものです。みんなが同じ言葉を使うので、理解しやすくなります。
- Bounded Context Modelは、それぞれのグループが自分たちの文化や方言を持っていて、その方言を尊重しながら交流するようなものです。それぞれが自分にとって使いやすい言語を使い、必要に応じて翻訳します。
まとめ
- Canonical Modelは、システム統合における「共通の言語」を作り、データの一貫性を持たせるために使います。
- Bounded Context Modelは、システムの内部で各ドメインがそれぞれに最適なデータ形式を使い、違いを尊重しつつ協力するために使います。
それぞれのアプローチには長所があり、プロジェクトの性質や目的に応じて使い分けることが大切です。