このエントリーは、「ドメイン駆動設計 #1 Advent Calendar 2018」の25日目、最終日の記事です。
24日目は、@j5ik2oさんの「混在したモデリングパラダイムの中で学ぶ重要なこと」でした。
今年は「ドメイン駆動設計」単独のテーマに対して#2もできるくらい盛り上がっていて、たくさんの方々のたくさんの知見が見れて大変楽しんでおります。私はクリスマス前の3連休でエントリを仕上げる素敵なカウントダウンができました。
では、最終日の記事を御覧ください。
問題意識
コンテキストマップはプロジェクトの全体感を捉え続けるために有用な補助ツールです。『エリック・エヴァンスのドメイン駆動設計』の4章戦略的設計で紹介されてるプラクティスです。筆者は複雑なソフトウェアに立ち向かう時によく利用します。
筆者はいくつかのチームでコンテキストマップの運用経験して運用の難しさを感じました。コンテキストマップの具体的な運用方法が明示されていないことと得られる効果が抽象的に説明されていることが難しさの要因です。コンテキストマップは関係者及びチームで育てていくモデリング手法です。目的を明らかにし運用方法を決めなければ形骸化してしまいます。
本エントリではコンテキストマップを作成する目的を再考した後に、コンテキストマップの運用のヒントとなる手引きを紹介します。
複雑な問題に立ち向かうためのコンテキストマップ
複雑な問題領域、複雑なシステムに立ち向かう重要な原則として、「分割統治」と「関心の分離」が挙げられます。大きな問題を小さな問題に分解し、それぞれの関心(責務)を分離することで複雑性に立ち向かいます。問題を分割しその構成要素をどこに配置されるかを決定させることで問題の透明性が高くなります。
これら原則はオブジェクト指向でも語られていますが、単にクラスやモジュールだけで活躍する原則ではありません。むしろクラスやモジュールだけで適用する場合、限定局所化された問題解決になる可能性があります。問題を分割するにあたって責務、つまり変更理由となる単位で分割しないと変更に強い柔軟なシステム作ることが困難であり、システムの変更理由は組織・チーム事情やステークホルダーの要求、外部システムなどのシステム外部要因によって発生するからです。筆者はこれらの外的要因がシステムの複雑性を上げる主要因だと考えています。
「木を見て森を見ず」にならぬようシステムの全体感を捉えて分割統治するためにコンテキストマップを利用します。
解決領域の分割統治
コンテキストマップは境界づけられたコンテキストの関係性を評価/概観します。境界づけられたコンテキストはシステムの解決領域を切り取ってユビキタス言語として言語化されます。複雑なシステムにおいてドメインモデルが複数のコンテキストをまたぐことはよくあります。1つのモデルが片方の解決するともう片方の解決方法に矛盾が生じてしまう場合は単一責任原則に違反しているように思いますが、境界づけられたコンテキストを使って双方の解決領域に適したモデルを育てるための区分けをしていきます。
境界づけられたコンテキストの関連性を図面化したものがコンテキストマップです。関連性を確認しながら継続的な統合を行うことでドメインモデルの一貫性が保たれます。
チームの分割統治
1つのシステムに対して複数の開発チームが存在するは往々にしてあります。
1つの境界づけられたコンテキストに1チームの場合、コンテキスト内部の関心事に集中できドメインモデルを発展させていけるチーム状態に近づけます。
とはいえ、最初から1つの境界づけられたコンテキストに1チームとするのは早すぎる意思決定になるかもしれません。1つのチームで境界づけられたコンテキストをまたぎながら徐々に分割を進めていくことが現実解であることもあるでしょう。
境界づけられたコンテキストに複数のチームが存在する場合、ドメインモデルの一貫性を保つのにコストがかかり、意思決定の速度が遅くなるためおすすめできません。
また、コンテキスト外のステークホルダーや外部システムの関係をモデルに適用しなければならない場面もあります。それらの制約の現状がどのようになっていて、今後その制約とどう立ち向かっていくかを考えるヒントになるでしょう。
運用の仕方
最初から完璧なモデルができないのと同じように、最初から完璧なコンテキストマップは作れません。
モデルの探求によって発展することもあるし、実際にデリバリしてみて気付くこともあるでしょう。
境界づけられたコンテキスト単位にマイクロサービス化した方がいいという主張もあり私も賛同していますが、不確実な中でどこまで先を見越すかのトレードオフはアーキテクトは常に考えておいた方がよいでしょう。筆者は漸進的に不確実性を取っ払いながらリファクタリングしていく手法を好んでいます。
As-Isを明らかにする「境界を見つける」「境界に言葉をつける」「境界の関係性を明らかにする」でコンテキストマップを利用し、「継続的な統合を行う」で得られたフィードバックを受け、必要に応じてコンテキストマップないしはモデルのTo-Beを検討するようなサイクルで徐々に非確実性を整理して意思決定すればいいと思っています。
境界を見つける
コミュニケーション構造から境界を見つける
コミュニケーション構造がコンテキストに紐づくことがあります。チーム内で行うコミュニケーションとチーム外で行うそれとでは頻度も質も異なります。コミュニケーション構造の多くはチームないし組織構造が物語ります。チームや組織の構造が組織のコミュニケーション構造をそのまま反映した設計になるという”コンウェイの法則”を参考にすることは理にかなっています。
内部制約から境界を見つける
チームや組織内部でもサブシステムや異なる関心事のインフラストラクチャを運用していたり、プログラミング言語が異なっていたりする場合があります。これらは何かしらの歴史的経緯や目的があった結果であるため境界になり得る可能性があります。
外部制約から境界を見つける
外部システムと連携する場合はそれ自体が境界になり得ます。外部システムは解決する目的がそれぞれ違う可能性があるからです。
また、ステークホルダーが複数で構成される場合も境界になり得ます。各々のステークホルダーの要望や利害を同一の解決方法で満たすことが現実的でない場合は境界を敷いた方がよいでしょう。
境界に言葉をつける
「この境界の関心事はなんでしょう？」
「解決している内容を一言で表すと何でしょう？」
上記の問いで解決している内容を言語化します。
これはユビキタス言語としてチームで運用され共通の言語として使われます。
境界の関係性を明らかにする
- パートナーシップ
- 顧客/供給者の開発チーム
- 順応者
- 別々の道
- 公開ホストサービス
- 公表された言語
- 共有カーネル
- 腐敗防止層
- 巨大な泥団子
上記のパターン・ランゲージによって関係性を明らかにします。パターン・ランゲージは認識差異を埋めるための土台として役に立ちます。
これらの関係性はそれぞれメリットデメリットがあります。後続の継続的な統合を行うことで関係性をリファクタリングしていきましょう。例えば結合度がボトルネックで共有カーネルがコンフリクトする頻度が多い場合は関係性を公開ホストサービスにリファクタリングを検討する等が考えられます。
継続的な統合を行う
ドメインモデルの一貫性を維持するために、継続的な統合が重要な役割を果たします。
コンテキスト内でないしはコンテキストをまたぐテストを行いドメインモデルにフィードバックをもたらします。ドメイン駆動設計においては概念の統合という観点に重きが置かれていますが、統合することで継続的に受け入れ条件を満たしていくようなスクラムのような観点を持ってもよいでしょう。継続的な統合は文字通り継続的に実施するのでテストは自動化しておいた方がよいでしょう。
最後に
結局、抽象度が高いエントリになってしまった気もしますが、以上となります。
色々書きましたがコンテキストマップは複雑なソフトウェアに立ち向かうための手段なので、これに固執せずにより目的合理的な手段があればそれを使えばいいと思います。
