モデルの整合性に関するパターン、に関するトレードオフ
トレードオフ p396より
https://gyazo.com/8369749a14964ba9c45cfe3f3387f339
機能のシームレスな統合による利益と、調整やコミュニケーションという追加作業との間でトレードオフを考えることになるのだ。より独立した活動をとるか、よりスムーズなコミュニケーションをとるかである。
主なやり方
単一コンテキストへのマージであっても、まずはここから行うべし言うてる
小さいサブドメインでまずはワンパスを通す
これによるマージプロセスが確立される
マージの3アプローチ
モデルを1つ選んで、それに合わせるようリファクタ
お互い自分のモデルに、一度に一部ずつマージしてクオリティ高めていく
新しいモデルを見つける
両チームから集めた2-4人で共有モデルを検討する
開発者はその共有モデルに従ってつくり、問題があるならフィードバックする（必要ならチームを再招集してモデルを修正する）
チーム間でメンバーをローテーションすべし言うてるねsta.icon
両方のモデルを理解している人をプールできる
これが確立されてくると、以下のいずれかになる
1つの大きなチームができている
2つの小さなチームがコードベースを共有し、継続的な統合を行い、メンバーを頻繁に入れ替えている
レガシーシステムの段階的な廃止
1回のイテレーションでつくれる単位で腐敗防止層に追加していく
実地で稼働した後は、腐敗防止層にある不要な部分を除去していく
これを何度も繰り返す
なるほど、腐敗防止層というラッパーを介して実装・除去をしていくのかsta.icon
年単位の仕事になるのもざらみたいsta.icon
Q: レガシーシステムそのもの廃止はどうするねん？
どこかのタイミングで大々的な廃止や切り替えができると思うので、そこでやる
それまではレガシーシステムそのもののタッチは無視して、腐敗防止層に留める
一時しのぎのプロトコル作ってきたけど、きつくなってきたから業界標準の用語使おうぜ、など
良さそうな言語がない場合、「ホストとして機能するシステムのコアドメイン」を土台として言語をつくれ、言うてるねsta.icon
その場合もXMLなど既知のパラダイムを使うのが無難らしい