実践DDD本 第3章「コンテキストマップ」～「境界づけられたコンテキスト」の関係を俯瞰する地図～

IDDD本から理解するドメイン駆動設計 第3回

コンテキスト間の連携のシーケンス図

　上記のことを踏まえた上で「アジャイルプロジェクト管理コンテキスト」と「認証・アクセス管理コンテキスト」間の連携の流れについて描かれたシーケンス図を見てみましょう。

コンテキスト統合のシーケンス例

　このシーケンス図は、左側「アジャイルプロジェクト管理コンテキスト（下流）」から開始し、中央の「腐敗防止層」を経て、右端「認証・アクセス管理コンテキスト（上流）」の「公開ホストサービス／公表された言語」を呼び出しています。

　上流側の公開ホストサービスでは、認証メンバーの変更状態を通知するAPI（この例では「https://{ドメイン}/tenants/notifications/{id}」）を提供しています。下流側のコンテキストが複数ある場合、この変更状態を使用するコンテキストだけが、このAPIを呼び出します。

ミニマル指向によるモデルの分離

　シーケンス図にある通り「アジャイルプロジェクト管理コンテキスト」では、腐敗防止層として専用のアダプタとファサードを作成しモデルの変換処理を行っています。そのため、上流のモデルの概念が、下流のコンテキストモデルに入り込まないようになっています。

　このようにコンテキスト間で同期するデータを最小にし、リモートモデルの属性のうち必要なものだけをローカルモデルに連携させることを「ミニマル指向」と呼びます。リモートモデルへの依存を減らすことで、自コンテキストのモデルに他の概念が混ざらなくなります。また、不必要な属性の同期がなくなるため、処理がシンプルになります。

SaaSOvationにおける実装方法のまとめ

　このシーケンス図では上流側のWebサービスを呼び出していますが、リアルタイム性が必須ではありません。この構成であれば、「認証・アクセスコンテキスト」のWebサービスがダウンしていても「アジャイル管理コンテキスト」が影響を受けず独立して動作することが理解いただけると思います。

　従来の開発であれば、1つのDBにしてしまったり、Webサービスと密結合にしてしまったりと、依存関係が高くなる課題を抱えていましたが、このDDDの例ではコンテキスト間の関係を疎結合にして、相互の依存関係を低くしています。

SaaSOvationの組織パターン

　最後に組織パターンの観点からも確認してみます。SaaSOvationの場合「コラボレーションコンテキスト」と「アジャイルプロジェクト管理コンテキスト」間の関係は「顧客／供給者」と考えられます。SaaSOvationは同一組織で開発しているシナリオのため、あまり難しくありませんが、実プロジェクトでは他のチームとの関係が不明瞭な場合も多いため、適切に情報を収集し組織パターンを明確にするようにします。

最後に

　本稿では、コンテキストマップについて紹介してきました。単純なサブシステム構成図のように思われがちですが、最適な連携方法を探るコミュニケーション図であることが理解できたと思います。コンテキストマップはDDD開発において非常に重要な図ですので、目立つところに貼って、チームで共有するよう努めてみてはいかがでしょうか。

　次回の第4回では、DDDのアーキテクチャについて紹介します。

参考資料

• コンテキストマッピングによる戦略的ドメイン駆動設計（Alberto Brandolini 氏の記事）（InfoQ）
• Context Map パターン 実践ガイド（システム設計日記）
• コンテキストのモデリング（システム設計日記）
• ドメイン駆動設計・大規模戦略編・コンテキストマップ（ストラテジックチョイス）
• 始めよう! ドメイン駆動設計＆マイクロサービス開発（Silideshare）