継続的な統合
多くの人々が同一の境界づけられたコンテキストで作業していると、モデルが分裂する傾向は強くなる。チームが大きければ大きいほど、問題も大きくなるが、3、4人ほどの少人数でも深刻な問題に直面することがある。しかし、システムをさらに小さいコンテキストに分割してしまうと、結局は有益なレベルで統合し、一貫させることができなくなる。
【中略】
ドメイン駆動設計にある他のパターンと同様、継続的な統合も2つのレベルで作用する。それが、①モデル概念の統合と②実装の統合である。
【中略】
実装成果物の統合は、システム的なマージ/ビルド/テストのプロセスによって実現され、モデルの分派を早い段階で明らかにする。統合に向けて多くのプロセスが用いられるが、効果的なもののほとんどは、次のような特徴を共通して持っている。
- 段階的に行われ、再生可能なマージ/ビルドテクニック
- 自動化されたテストスイート
- 変更が統合されない期間に対して、妥当な短さの上限を設定するルール
効果的なプロセスに置いて実装と対になるのが、概念の統合である。ただ、これが正式に含まれることはめったにない。
- モデルとアプリケーションに関する議論における、ユビキタス言語の絶え間ない鍛錬
CIで行うことは、実装の統合と概念の統合とある。なるほど…。これは深い…。概念の統合については、スクラムをうまく使ってプロセス化できないものか。
全てのコードと外の実装成果物を頻繁にマージさせるプロセスを策定すること。その際、分裂に対して素早く警告する自動化されたテストも一緒に用いること。ユビキタス言語の執拗な鍛錬を絶え間なく行い、モデルに対する共有された見方を練り上げること。概念は、別々の人の頭のなかで進化していくからだ。
最後に、仕事を必要以上に大きくしないこと。継続的な統合が不可欠になるのは、境界づけられたコンテキスト内だけだ。隣接したコンテキストを巻き込んだ設計に関する問題は、変換も含め、同じペースで取り扱わなくても良い。
最後の一文について、ここでは答えが書かれていない。まだ読んでないのか、読んでるけどわかっていないのか。この部分をどうしていければいいのか、もっと深く探求しよう。
