【DDDメモ】モデルの整合性を維持する:共有カーネル

共有カーネル

エリック・エヴァンスのドメイン駆動設計 P.363

 まとまりのない複数のチームが、密接に関連したアプリケーションに取り組んでいると、暫くの間は作業を急いで進めることができても、それぞれが作り出すものはうまく適合しないだろう。結果的に、初めから継続的な統合を行った場合よりも多くの時間を、変換層と修復作業に費やすことになり、この二度手間のせいで共通のユビキタス言語が持つ利点を失うことになる。
 多くのプロジェクトにおいて、大部分は独立して作業している複数のチーム間で、インフラストラクチャ層が共有されているのを私は見てきた。これと似たようなことが、ドメインの中でもうまく機能することがある。モデルとコードベース全体を完全に同期させるとオーバーヘッドが大きくなりすぎるかもしれないが、慎重に選択したサブセットを同期するのであれば、少ないコストで利益のほとんどを得られる。
 それゆえ:
 2つのチームが共有することに合意したドメインモデルのサブセットを指定すること。もちろん、これには、モデルのサブセットに加え、コードのサブセットや、モデルの該当箇所に関連するデータベース設計も含まれる。この明示的に共有されたものには、特別な地位が与えられているので、もう一方のチームに相談せずに変更してはならない。
 稼働しているシステムは頻繁に統合すること。ただし、チームの中で行われる継続的な統合よりは、やや頻度を下げること。この統合の際には、両チームのテストを実行すること。

 このような状態は容易に予測できる。複数のコンテキストまたはチームで相互参照する、もしくは共通的なドメインやインフラストラクチャが存在することはあるだろう。そういう部分について、明確に定義した上で、複数チームで共有するというのは、効率的な部分があるだろう。
 ただ、3チーム、4チームと共有するチームが増えてくると話は別だろう。その場合は、「別々の道」をあえて選んだほうがうまくいく場合もあるのではないだろうか。そういう意味で、共有カーネルの考え方は、プロセスの高度化も含め、プロジェクト進行中においてもチームが判断できるような状態にする必要があるのではないだろうか。