ddd-context-mapping

一行での概要

コンテキストマップは、境界づけられたコンテキスト同士の関係を記録し、境界を越えてモデルを変換する統合パターンを選定します。

このスキルを使う場面

• 別のチームのドメインモデルと統合する場合。
• 新しいシステム間の境界に適した統合パターンを決める場合。
• チームが利用する必要はあるものの、変更できないレガシーシステムがある場合。
• ユーザーが、コンテキストを分割すべきかどうかではなく、コンテキスト同士がどのように連携するかを尋ねている場合。

このスキルを使わない場面

• コンテキスト内のモデリング → ddd-bounded-context または戦術的パターンのスキル。
• 境界そのものを定義する場合 → ddd-bounded-context。
• サブドメイン間で何に投資するかを選ぶ場合 → ddd-subdomain-classification。

主な内容

選定基準を含む、7つのパターンです。

共有カーネル（Shared Kernel）。 2つのコンテキストが、モデルの小さな一部分（たとえば、ごく小規模な値オブジェクトの共有ライブラリ）を明示的に共有し、保守します。チーム同士が緊密に連携している場合は低コストです。連携が不十分だと脆弱になり、変更のたびに両チームの合意が必要になります。

顧客–供給者（Customer–Supplier）。 下流側が上流側に依存し、上流側は計画において下流側のニーズを優先すると約束します。上流チームが下流チームに対して責任を負う意思がある場合に有効です。

適合者（Conformist）。 下流側は上流側のモデルをそのまま受け入れ、それに適合します。上流側に影響を与える手段がなく、適合するコストが変換するコストを下回る場合にのみ使用します。これは意図的な戦略上の選択であり、怠慢ではありません。

腐敗防止層（Anticorruption Layer／ACL）。 下流側が所有する変換レイヤーで、独自のモデルを外部または不安定な上流モデルから隔離します。上流モデルに適合すると自らのモデルが損なわれる場合に使用します。通常は、レガシーシステムやサードパーティ API との統合時に適しています。

オープンホストサービス（Open Host Service／OHS）。 上流側が、複数の下流コンシューマー向けに設計された安定したプロトコルを提供します。同じ上流側を必要とする下流側が N+ 個ある場合に使用します。安定したインターフェースのコストを一度負担すれば済みます。

公開言語（Published Language）。 複数のコンテキストが合意する、正式で十分に文書化された交換形式（スキーマやプロトコル）です。オープンホストサービスと組み合わせられることがよくあります。この形式は実装の詳細ではなく、契約の一部です。

別々の道（Separate Ways）。 2つのコンテキストは統合を見送り、小さな重複は複製します。統合コストが重複コストを上回る場合に使用します。チームが認めるよりも、こちらが正解となることはよくあります。

同じカタログによく含まれるアンチパターンもあります。

泥団子（Big Ball of Mud）。 境界がまったくありません。これを認識し、泥団子を封じ込めるようにコンテキストマップで囲み、統合する場合は（通常は ACL を介して）統合し、拡張はしないでください。

判断のヒント

• 上流側の内部ではなく、上流側の安定したインターフェースを対象に統合します。
• 上流モデルが外部のものである、不安定である、または影響を与えられないチームが所有している場合は、必ず ACL を構築します。
• 別々の道も現実的な選択肢です。「統合しない」が正解となることもあります。
• 適合者は戦略上の選択です。デフォルトではなく、意図的に選びます。

アンチパターン

• 依存しているレガシーシステムを「モデル」と呼ぶこと。そうではなく、上流コンテキストです。
• 明確な変換ルールのない ACL を構築すること。単なるパススルーになります。
• 連携していないチーム間でカーネルを共有すること。カーネルは劣化します。
• インターフェースを実際には安定させていないのに、「オープンホストサービス」と宣言すること。

関連項目

• ddd-bounded-context — 関係をマッピングする前に、境界がどこにあるかを定義します。
• ddd-anti-patterns — 泥団子やその他の統合に関するアンチパターンを扱います。

参考資料

• Evans, Domain-Driven Design（2003年）、第14章（モデルの整合性を保つ）。