BOUNDED CONTEXT (P335) †
要約 †
問題についての説明
大きなプロジェクトでは複数のモデルが共存し、多くの場合うまく機能します。異なるモデルが異なるコンテキストで適用されるというわけです。コンテキストの違いが明確な場合は問題ありませんが、この章の最初の例のようにあいまいでわかりにくい状況もあります。
単一のチームが複数のモデルを持つことさえあり得ます。その場合は、複数モデルの存在により、コミュニケーションが難しくなりモデルの解釈に混乱が生じます。
根本的な問題は、システム間でデータフォーマットが異なりデータの変換が必要だということではなく、システム間でモデルに隠れた違いがあることです。この矛盾が同じコードベースの中にあるとき、これはほとんど認識されません。しかし、このことはすべての大規模チームのプロジェクトで起こるのです。
問題サマリ
異なったモデルのコードベースが一緒になると、ソフトウェアはバグを含みやすくなり、信頼できなくなり、理解しにくくなります。そしてチームメンバー間のコミュニケーションは混乱します。あるモデルをどのコンテキストで使うべきでないかが不明瞭なことが多くあります。
解決方法についての説明
モデルのコンテキストを明確にするには、プロジェクト（チームの編成、人のやり取り）とプロダクト（コード、データベーススキーマ）の両方を見る必要があります。プロジェクトに関することが問題の始まりであり、その結果がプロダクトの不具合として表れるからです。
あるモデルは特定のコンテキストの下で使用されます。モデルのコンテキストとは、モデルに関する用語が特定の意味を持つために適用されなければいけない条件の集合です。
複数モデルの問題を解決するには、特定のモデルのスコープを明確に定義する必要があります。この定義がチーム編成を調和したものにしなければいけません。
解決方法サマリ
モデルが適用されるコンテキストを明確に定義してください。チーム編成、アプリケーション部品内における（モデルの？）利用法、コードベースやデータベーススキーマなどの成果物、これらについて境界を明確に設定してください。モデルをその境界の中で厳密に一貫性あるものに保ち、境界外の問題に惑わされたり混乱させられたりしないでください。
結果
BOUNDED CONTEXTが特定のモデルをどのコンテキストで使用すべきかの境界を定めます。そのため、チームメンバーは、何が一貫性を持つべきでそれがどのように他のCONTEXTに関係するのかについて理解できるようになります。境界を引くことで、モデルを純粋にそして効果的なものに保てます。同時に、他のコンテキスト間での混乱を避けられます。
例:予約コンテキスト †
貨物予約のアプリのモデルを含むBOUNDED CONTEXTとは何でしょうか？これに答えるために、プロジェクトに起きることをあるがままに見る必要があります。
- プロジェクトチームは予約アプリそのものに取り組みます。モデルは予約アプリ内で妥当です。したがって、予約アプリは境界内です。
- 予約を完全なものにするには予約情報をレガシーなトラッキングシステムに渡す必要があります。新しいモデルをレガシーなモデルから切り離すという決定がされます。したがって、レガシーなトラッキングシステムは境界外です。
- 新しいモデルからレガシーなモデルへの変換はレガシーチームの責任です。したがって、モデルの変換は境界外です。
- モデルに責任を負うチームは永続化を含めすべてのライフサイクルを扱います。データベーススキーマはモデルから作成されます。したがって、スキーマは境界内です。
- 貨物船のスケジュールのために他のチームがモデルに働きかけます。予約チームとスケジューリングチームは実際には異なるCONTEXTにいますが、それに気づかないで統一されたモデルを作ろうとします。ここにはリスクがあります。コードの共有を止めるべきです。
ここまでで、BOUNDED CONTEXTについて次のことがわかります。
- 予約アプリのモデリングチームとアプリチームがこのCONTEXTにいる。
- 情報はレガシーチームと交換されなければいけない。レガシーチームはモデリングチームからの協力を得て、境界で変換を行う責任がある。
- 予約モデルとスケジュールモデルの関係があいまい。この関係を定義することが予約チームとスケジュールチームの最初の仕事であるべき。
BOUNDED CONTEXTを定義することで何が得られたでしょうか？
- CONTEXT内で作業するチームにとっては明瞭さ（1つのモデルに調和しなければいけないとわかる）
- CONTEXT外で作業するチームにとっては自由（同じモデルを使う必要がない）
- 非公式な情報を共有することのリスクについての認識
＊ ＊ ＊
境界は特別な場所です。接しているBOUNDED CONTEXT同士の関係は注意深く扱わなければいけません。COTEXT MAPによりCONTEXTとその関係について見取り図を示すことができ、CONTINUS INTEGRATIONによりモデルの統一状態を保てます。
BOUNDED CONTEXT内にある分裂を認識する †
多くの兆候により、認識されていないモデルの違いが示されるといったことがあります。兆候には、コードのインタフェースが一致しない、システムが予想外の振る舞いをするといったものがあります。自動テストを使ったCONTINUOUS INTEGRATIONのプロセスがこれらの問題を見つけるのに役立ちますが、初期の警告は、通常、言語の混同が原因です。
異なったモデルの要素を一緒にすると2種類の問題が生じます。重複した概念（duplicate concepts） と 偽同族語（false cognates）です。
重複した概念は、実際には同じ概念を指す2つのモデル要素が存在することを意味します。重複した概念により、一方に修正が入ると他方にも修正が入る、チームメンバーが同じことをするのに2通りの方法を学習せねばならないといった問題が生じます。
偽同族語は、2人が同じことについて語っていると考えながら同じ用語を使っているが、実は違っているというというものです。この章の最初の例が典型的です(Chargeと呼ばれる異なるビジネスの活動があった)。偽同族語により、あるチームが他チームのコードを壊してしまったり、データベースが矛盾を抱えたり、チーム間のコミュニケーションに混乱が生じたりということが起こります。
このような問題を見つけたとき、分裂をひとつにまとめるかそれとも異なったものとして認識するかはチームが決定しなければいけないでしょう。このような問題を扱うことが、この章の残りのパターンの主題になります。
担当者のつぶやき †
みんなの突っ込み †
