これまでの十四章

パターンを選択する

ここまで、統合パターンを幾つか見てきましたが、実際どう選択していくのかがテーマ

この意思決定はチーム全体が理解をするようにすることが大事。
意思決定自体は、政治的な都合、運用の都合、費用対効果の都合もあるので、現実的に選択することです。

自らがコンテキストの一部であることを意識し設計すること。それをコンテキストマップに反映することです。

モデルが一貫性を持つようになるので理解しやすく、コミュニケーションも取りやすい反面、変換が難しい可能性があります。かつ、モデルが大きい分用途の広いモデルを必要とされることがありますが、そのためのスキルが必要になってきます。

モデルが小さくなるので開発者間のコミュニケーションオーバーヘッドは減少し、継続的な統合もしやすくなります。一方で、ユビキタス言語の方言が増えるので注意。

このバランスを取るのは苦労するとのことです。あっ実際苦労してますね。。。自分の場合。。。

最も簡単に意識決定できるのは、置き換え予定のないレガシーシステムや外部システムですね。ここはまずコンテキスト外になるでしょうから簡単に線が引けます。

レガシーシステムが変更してくれる、統合を促してくれる場合もありますが、それは当然と思ってはいけないと言っていますね。

統合が必要なければそれにこしたことはないですよね。
ユーザーが両方のシステムをいじればいい場合もありますし、そこは慎重に検討すべきところです。

統合が必要であれば、どちらかをまず考えます。

順応者は、楽しくないですよね。特に新システムの場合はなぜ作るのかという疑問が出てきてしまいます。
それでも順応者を選択できる場合としては、Excelや単純なツールでレガシーで巨大システムの拡張をするような場合。。。こんなケースありそうですね。。。

そうでなければ、腐敗防止層を選択します。

チームが大きくなり、継続的な統合が困難になったら、共有カーネルを探して境界づけられたコンテキストに切り離して、そこに開発者を割り当てましょう。

また、依存関係が一方向であれば、顧客/供給者の開発チームを選択します。

デプロイはコンテキスト間の統合が絡むと大変な作業になるのは目に見えていますね。
逆に言えば、統合で危険な箇所がデプロイによってわかるというものです。

デプロイの計画をコンテキスト境界の引き方にフィードバックすることで調整しやすくなるでしょう。
もちろん別々の道であれば作業は楽になりますね。

明日は、プロジェクトの途中で統合のパターンを変更する場合について読んでいきます。