DDD/Chapter Fourteen. Maintaining Model Integrity

モデル完全性の維持 (331ページ) †

私は過去に大規模のシステムを複数のチームが平行して動くプロジェクトに関わったことがある。あるチームがChargeオブジェクトを作ろうとしたところ、別のチームが既に実装していたのでそれに「費用コード」追加の他にいくつかの変更をして動かした。

数日後、Chargeの元々書かれていた部分にて不具合が起き、特定動作で暴走した。

これは2つのグループが異なるモデルを持ち、矛盾を解決せずに結合してしまったために問題が起こってしまった。

2つのグループが、共同作業をして不具合を未然に防ぐよう自動テストをするか、別々のモデルを作ってお互いのコードに干渉しないようにするか、などのモデルの適用範囲の境界を決めておく必要があった。

結局彼らはCustomer ChargeとSupplier Chargeとに別々にクラスを作成して解決することにした。

モデルの最も基本的要件は、内部的に一貫していることである。各用語を明確にしてルールを矛盾させないことを統一性(unification)という。理想は企業全体のドメインで単一のモデルを持つことだ。

しかし大規模システムの世界において、全体で統一レベルを維持するのは不可能または難しい割に得るものが少ない。どれが複数のモデルを許すのかなどを慎重に決定し、重要な部分をしっかりと統一しておく必要がある。

多くの人は、複数モデルを扱うことで統合が厳しくなったり厄介なコミュニケーションをしたりすることになるだろう。複数のモデルをなくそうとするのは非常に意欲的な試みだが、リスクには十分注意しなければならない。

何の技術的問題が無くても、チーム間の政治やマネージメント上の優先順位などでモデルの相違が発生し複数のモデルが生まれてしまう。

全体で統一したモデルを維持できなくとも、何を統合すべきで何を統一しなくてもよいかの認識を共有していれば、全体像がはっきりして統一すべきパーツの維持に注力できる。

我々には異なるモデル間の境界や関係を示す方法が必要だ。また、意識的な戦略の決定を行い、一貫してその戦略に従う必要がある。

BOUNDED CONTEXTは各モデルの適用範囲を定義し、CONTEXT MAPによってプロジェクトの全体像やモデル間の関係を把握する。CONTEXT BOUNDEDを持った後は、CONTINUOUS INTEGRATIONによってモデルを統一に保っていく。

この安定した状態から始め、BOUNDING CONTEXTSや、SHARED KERNELSで密接に結びついたコンテキストからSEPARATE WAYSにする疎結合のモデルまでに渡り、より効果的な戦略に移行し始めることができる。