CommentDDDを読みながら、「大きなプロジェクトでは、モデルや共通言語を共有するなんて難しいんじゃないだろうか」という、浅い考えを持っていました。*1しかしながらEvansさんは、そんな単純な疑問については、ちゃんと第14章で回答を準備していたのでした。Integrity」は、モデルの整合性について記述した章。システムのモデルとしては、完全に整合性の取れたモデルが1つ存在するのが望ましい。システムの複雑さ、組織体制、プロジェクトにおける政治的な理由などから、大きなプロジェクトでは、各チームごとに、複数のモデルが作られるのが一般的。そのようなモデル間の整合性の保ち方を、以下の各パターンを使って説明している。CONCEXTシステムにおける各モデルの境界を、明確に定義することの必要性について言及している。CONTEXTによって、そのモデルがシステムのどの範囲に適用されるかという線が引かれる。INTEGRATIONモデルの境界が明確になったら、その境界内のモデルを健全に保っていかなければならない。Integrationが有効。継続的インテグレーションとして有名ですね。MAP各モデル間の関係を表したマップ。システム全体を俯瞰するために必要。KERNELシステムのコアとなるモデルを、複数のモデル(チーム)間で共有するパターン。当然ながら、複数のモデル間で共有されるコード、DBスキーマなどの扱いについては注意が必要。KERNEL部分を修正する場合は、各チーム間で充分に話し合わなければならない。TEAMSモデル間の処理の流れに着目し、処理の下流となるモデル(チーム)がカスタマー、上流となるモデル(チーム)をサプライヤーと定義する方法。サプライヤーはカスタマーの要件を満たすようにインターフェースを定義しなければならない。下流チームをお客様として扱う。TEAMSとは逆に、下流のモデル(チーム)が、上流のモデル(チーム)にモデルを適合させるやり方。組織の力関係などによっては、この方法をとらざるを得ない場合も多いですね。LAYERモデルの境界に、モデル間の「通訳」を行わせるレイヤーを準備する方法。外部とのやり取りはこのレイヤーを通じて行うことで、各モデルへの影響を最小限にする。レイヤーをワンクッション入れることで、モデルの差異を吸収するやり方。WAYSモデル間に重要な関係がほとんど無い場合、各モデルを独立させてしまうというやり方。極論すると、相手のモデルを無視し、独立独歩で開発を進めていく方法。過去の日記で言及した「分割統治」は、このイメージにちょっと近い。SERVICE多くのシステムから利用されるサブシステムについて、そのサブシステムの機能を「サービス」として提供する方法。すべてのシステムに対する「通訳」レイヤーを準備するのに比べ、変更に対して柔軟に対応することが可能となる。LANGUAGEモデル間のデータ交換などのために、そのドメインの本質をよく定義した共通言語を使用する方法。ちなみに、DDDのパターン一覧がここにコンパクトにまとめられています。*1:過去の日記でも、それに近いこと書いてました。コメントをキャンセルメールアドレスが公開されることはありません。ThemeHall.。