ドメイン駆動設計（DDD）は、顧客と開発者がビジネスを戦略的に理解し、共通の言葉を用いてシステムを発展させていく設計手法です。前回は集約を格納／取得する「リポジトリ」について紹介しました。第13回となる今回は「境界づけられたコンテキストの統合」について解説します。
「境界づけられたコンテキスト」と「コンテキストマップ」
DDDではシステムをひとつの大きな固まりではなく、ビジネス的な境界線（ユビキタス言語の境界線）にあたる「境界づけられたコンテキスト」の単位で分割して管理することを2章で紹介しました。この「境界づけられたコンテキスト」の関係を示す図が3章で紹介した「コンテキストマップ」となります。
コンテキストマップは、モデルの変更が影響を与える「上流（U）」とモデルの変更の影響を受ける「下流（D）」といった関係を示しつつ、相互にどのような方法で結合しているかを示します。上図では「認証・アクセスコンテキスト」「コラボレーションコンテキスト」「アジャイルプロジェクト管理コンテキスト」といった3つの関係を説明しています。
本稿では、これらのコンテキスト間での連携に必要な「分散システムの原則」「データ交換フォーマット」「Notification（通知）の仕組み」「RESTアーキテクチャ」「メッセージングアーキテクチャ」について紹介していきます。
分散システムの基本
まず「境界づけられたコンテキストの統合」において重要な概念となる「分散システム」の設計指針から確認していきましょう。DDDで複数の「境界づけられたコンテキスト」が存在する場合、通常それらは分散システム構成となります。
分散システム構築時の原則
分散システムの構築は一般的な集中システムに比べると簡単ではありません。そのため開発者は次の「分散コンピューティングに関する原則」を理解する必要があります。
- ネットワークは信頼できない
- ある程度の（時にはかなりの）遅延が常に発生する
- 帯域幅には限りがある
- ネットワークはセキュアではない
- ネットワーク構成は変化する
- 管理者は複数人存在する
- 転送コストはゼロではない
- ネットワークは一様ではない
この原則は、元サン・マイクロシステムズのドイチュ氏による「分散コンピューティングの落とし穴（参照：ウィキペディア）」として知られている内容を、IDDD本で逆に書き直した「原則」となります。
コンテキスト間の「データ交換フォーマット」
異なる「境界づけられたコンテキスト間」で情報を受け渡す場合、相互に解読できるデータ形式が必要になります。そのため、データ交換用のフォーマットを取り決める必要があります。IDDD本では「（1）共有カーネル」「（2）プログラム言語のシリアライズ機能の利用」「（3）中間フォーマット（JSON等）」「（4）カスタムメディアタイプ」といった4方式を示しています。
（1）共有カーネル
最初のデータ交換フォーマットとしては、3章にて紹介した「共有カーネル」が存在します。これは複数のコンテキスト間で同じソースコードを共有する方法です。しかしこの方法は、片方のコンテキストの変更が他のコンテキストに大きな問題を引き起こす危険性があるため、あまり使用しないほうが良いとされています。
（2）プログラム言語のシリアライズ機能
2番目の方法は、プログラミング言語（JavaやC#）の機能を使う方法です。これは、オブジェクトの情報をバイナリ形式でシリアライズして連携します。復元側でも同じプログラミング言語を使っている必要があります。さらに、異なるハードウェアや言語バージョンでも正しく復元できる必要があります。そのため他のプラットフォームとの接続などを考慮すると懸念点があります。
（3）中間フォーマット（JSON等）
3番目の方法は、標準化されている中間フォーマットを利用する方法です。主要なフォーマットとしてXML、JSON、Protocol Buffers等が存在します。それぞれ、サイズ／型変換／複雑なデータの扱い／バージョン互換においてメリットとデメリットが存在するため、プロジェクトに応じて採用するフォーマットを検討すると良いでしょう。
（4）カスタムメディアタイプ（MIMEタイプ）
4番目の方法として、標準規格に基づいた手法で定義できる「カスタムメディアタイプ（MIMEタイプ）（参照：ウィキペディア）」を利用することができます。
IDDDでは、RESTサービスに対するリクエストをJSONで戻す際に、以下のMIMEタイプによるレスポンスを返しています。
- application/vnd.saasovation.idovation+json
- application/vnd.saasovation.projectovation+json
- application/vnd.saasovation.collabovation+json
この「vnd.」というプレフィックスは「ベンダーツリー」と呼ばれ、公開されている製品に関連するメディアタイプとして用いられます。SaaSOvationのような公開サービスでは「公開された言語」の一部としてカスタムメディアタイプを定義しています。
以上、4つのデータ交換フォーマットについて紹介しました。
この記事は参考になりましたか？
- IDDD本から理解するドメイン駆動設計連載記事一覧
-
- 実践DDD本 第14章「アプリケーション」～ドメインモデルを利用するクライアント～
- 実践DDD本 第13章「境界づけられたコンテキストの統合」～分散システム設計～
- 実践DDD本 第12章「リポジトリ」～集約の永続化管理を担当～
- この記事の著者
-
WINGSプロジェクト 青木 淳夫（アオキ アツオ）
＜WINGSプロジェクトについて＞有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ（代表 山田祥寛）。主にWeb開発分野の書籍／記事執筆、翻訳、講演等を幅広く手がける。 2026年時点での登録メンバは約50名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書、記事多数。 RSS X: @WingsPro_info（公式）、@WingsPro_info/wings（メンバーリスト） Facebook
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
山田 祥寛（ヤマダ ヨシヒロ）
静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ（Java・C#・Python・PHP・Ruby・JSP＆サーブレットなど）」「速習シリーズ（ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど）」「改訂3版JavaScript本格入門」「これからはじめるLaravel実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
