前回のふりかえり
第14章 モデルの整合性を維持する
- システムが複雑になりすぎて個々のオブジェクトのレベルで理解することが出来なくなると、巨大なモデルを扱うためのテクニックが必要になる
- 非常に入り組んだドメインに対応させるための原則
- コンテキスト
- 蒸留
- 大規模な構造
- 第14章では、コンテキストについて説明
- コンテキスト境界
- 各モデルのスコープ(境界)を定義し、境界内はモデルを一貫性のあるものに保つようにする
- 継続的な統合
- コンテキスト内で行われるすべての作業について一貫性を保つことで、分派した時にすぐ発見して修正できるようにする
- コンテキストマップ
- コンテキスト同士の関係を明らかにするために作成する
- コンテキスト境界
第14章 モデルの整合性を維持する
コンテキストマップで用いられる、コンテキスト間の6種類の関係
共有カーネル
複数のチームが関わるようなプロジェクトでは、それぞれのグループが異なるモデルを持ち、自由に変更を加えて整合性が取れなくなることがある。その場合、モデルの一部を直接共有することで、少ないコストで統合しやすくなる。
[留意点]
- 共有カーネルは特別な部分になるため、他チームへの相談なしに勝手に変更を加えてはならない。
- 定期的に統合を行う。ただし、コンテキスト内ほど頻繁でない方がよい。
- 自動化されたテストスイートも統合する。
顧客/供給者の開発チーム
2つのシステムの関係が上流と下流(データを送る側、データを受け取る側)に分かれていることがある。その場合は、明確に顧客（使う側）と供給者（使われる側）という関係を確立してしまう。
- 上流側が供給者・下流が顧客の立場を取る。(供給者がシステムに責任を持ち、システムの在り方を決定する)
- 顧客の要求が最優先となるような関係でなければならない。
- 自動化された受入テストを共同で開発して、要件を満たしているか両者で確認する。
順応者
顧客/供給者の関係がうまく行かない(供給者が顧客を最優先してくれない等)時は、下記の選択肢がある
- 下流チームが上流に頼らないと決めた時は、別々の道を歩むことになる
上流の設計に問題があり、その設計を下流が使うのが難しい場合
- 独自のモデル(変換層)を作ることで対応する(腐敗防止層)
- 独自のモデルを使うことをあきらめる(順応者) // ここ
順応者は独自のモデルを作らず、あえて上流のドメインモデルに従う。
- それにより、複雑な変換処理を取り除くことができるという利点がある
- その一方で、自分たちでモデルを設計することはできない
腐敗防止層
新しいアプリケーションを作る時、たいていは独自のモデルを持ったレガシーな外部システム等と連携しなければならないが、既存システムのモデルは、新しく作るアプリケーションのドメインモデルにはそぐわないことがある。
- そのような場合は、両システムの間に隔離するためのレイヤを設ける（腐敗防止層)
- 双方のモデルを変換する役割を担うことで、モデル変換のコストを下げることができる
- ただし、腐敗防止層には構築するにあたってかなりのコストがかかる
別々の道
2つの機能が互いにとって不可欠でないのなら、完全に切り離してしまうこともできる。
- 統合にはコストがかかる。そのコストをかけずに済む。
- 個々の機能は自由にモデルを変更できることができる。
- ただし、完全に分離した後は統合がかなり難しくなる。未来の選択肢を減らすことになる
公開ホストサービス
あるサブシステムを他の多くのサブシステムと統合しなければならない場合、それぞれに対して変換サービスを作成するとチームが行き詰まる可能性がある。
- そのような場合、サブシステムにアクセスできるプロトコルを、サービスの集合として提供するのがよい。
- 新しい統合の要件に対応する場合は、プロトコルに機能を追加し、拡張していく。
- 特定のチームだけの要望は、別で変換サービスを用意する。
公表された言語
既存のドメインモデルへの直接的な変換や、既存のドメインモデルからの直接的な変換は、適切な解決策でないことがある。
- 情報をやりとりするには、双方のコンテキストの共通言語が必要
- 明確にドキュメント化された共有言語を使用することで、互いの解釈を合わせていく。
思ったこと・気になったこと
- 6つの関係の話、ここ最近の内容の中ではすっと入ってきた。腐敗防止層を設けられずにレガシーシステムに浸食されている機能、身近にたくさんあるなと思った
- 6つの関係以外にも面白い話があったが割愛。諸事情によりちょっと読破を急ぎます。
