コンテキスト間の連携のシーケンス図
上記のことを踏まえた上で「アジャイルプロジェクト管理コンテキスト」と「認証・アクセス管理コンテキスト」間の連携の流れについて描かれたシーケンス図を見てみましょう。
このシーケンス図は、左側「アジャイルプロジェクト管理コンテキスト（下流）」から開始し、中央の「腐敗防止層」を経て、右端「認証・アクセス管理コンテキスト（上流）」の「公開ホストサービス／公表された言語」を呼び出しています。
上流側の公開ホストサービスでは、認証メンバーの変更状態を通知するAPI（この例では「https://{ドメイン}/tenants/notifications/{id}」）を提供しています。下流側のコンテキストが複数ある場合、この変更状態を使用するコンテキストだけが、このAPIを呼び出します。
ミニマル指向によるモデルの分離
シーケンス図にある通り「アジャイルプロジェクト管理コンテキスト」では、腐敗防止層として専用のアダプタとファサードを作成しモデルの変換処理を行っています。そのため、上流のモデルの概念が、下流のコンテキストモデルに入り込まないようになっています。
このようにコンテキスト間で同期するデータを最小にし、リモートモデルの属性のうち必要なものだけをローカルモデルに連携させることを「ミニマル指向」と呼びます。リモートモデルへの依存を減らすことで、自コンテキストのモデルに他の概念が混ざらなくなります。また、不必要な属性の同期がなくなるため、処理がシンプルになります。
SaaSOvationにおける実装方法のまとめ
このシーケンス図では上流側のWebサービスを呼び出していますが、リアルタイム性が必須ではありません。この構成であれば、「認証・アクセスコンテキスト」のWebサービスがダウンしていても「アジャイル管理コンテキスト」が影響を受けず独立して動作することが理解いただけると思います。
従来の開発であれば、1つのDBにしてしまったり、Webサービスと密結合にしてしまったりと、依存関係が高くなる課題を抱えていましたが、このDDDの例ではコンテキスト間の関係を疎結合にして、相互の依存関係を低くしています。
SaaSOvationの組織パターン
最後に組織パターンの観点からも確認してみます。SaaSOvationの場合「コラボレーションコンテキスト」と「アジャイルプロジェクト管理コンテキスト」間の関係は「顧客／供給者」と考えられます。SaaSOvationは同一組織で開発しているシナリオのため、あまり難しくありませんが、実プロジェクトでは他のチームとの関係が不明瞭な場合も多いため、適切に情報を収集し組織パターンを明確にするようにします。
最後に
本稿では、コンテキストマップについて紹介してきました。単純なサブシステム構成図のように思われがちですが、最適な連携方法を探るコミュニケーション図であることが理解できたと思います。コンテキストマップはDDD開発において非常に重要な図ですので、目立つところに貼って、チームで共有するよう努めてみてはいかがでしょうか。
次回の第4回では、DDDのアーキテクチャについて紹介します。
