DDD
Shared Kernel †
要約 †
機能的な統合が制限されている場合、CONTINUOUS INTEGRATION（継続的統合）のオーバーヘッドが非常に高くなるかもしれない。これは、チームがスキルを持っていない場合、継続的な統合を維持する政治的な組織の場合、あるいは単一のチームが単純に大きすぎて扱いにくい場合に特に見られる。そのため別々のBOUNDED CONTEXTSが定義され、複数のチームが作られるかもしれない。
＊＊＊
- 緊密に連携したアプリケーションに関わるが、調整されていないチームの場合、しばらく競争しながら進むかもしれないが、成果物は互いにフィットしないかもしれない。結局、最初からCONTINUOUS INTEGRATIONを行った場合に比べ、翻訳のレイヤーや修復作業に多くの時間を割き、作業が重複し、また共通のUBIQUITOUS LANGUAGEの利点を失うことになる。
- 多くのプロジェクトでは、インフラ層については非常に独立したチーム間で共有されるのを見てきた。これに類似したドメイン内のものについても機能する。
全モデルやコードベースを完全に同期を取るのはオーバーヘッドが大きすぎるかもしれないが、注意深く選択されたサブセットは、コストを下げる利点を与えてくれる。
Therefore:
- 二つのチームが共有に同意したドメインモデルのサブセットを指定せよ。もちろんこれには、モデルのサブセット、コードのサブセット、そのモデルに関連したデータベース設計のサブセットを含む。この明白に共有されたものは特別な状態にあり、他のチームとの協議なしに変更すべきではない。
- 機能的なシステムを頻繁に統合せよ。ただしチーム間のCONTINUOUS INTEGRATIONのペースよりは少なく。これらの統合では、両方のチームのテストを実行せよ。
- バランスに注意すること。SHARED KERNELは、設計の他の部分のように自由に変えることはできない。決定には、他のチームとの協議が含まれる。自動化されたテストスイートは統合されなければならない。なぜなら両方のチームの全テストは、変更が行われた際にすべてパスしなければならないからである。たいてい、チームは他のチームと定期的に統合を行いながら、KERNELの切り離されたコピーについて変更を行う。（たとえば、CONTINUOUSLY INTEGRATESを毎日あるいはより頻繁に行うチームでは、KERNELのマージは週ごとでよいだろう）。コードの統合がいつ行われるかに関わらず、変更について両方のチームが話し合うのが早ければ早いほどよい。
＊＊＊
- SHARED KERNELは、しばしばCORE DOMAINか、いくつかのGENERIC SUBDOMAINSのセット、あるいは両方の場合もあるが、両方のチームから必要とされるモデルのいずれかの部分となりうる。この目標は、重複を減らすこと（ただし除去することではない。というのもただ一つのBOUNDED CONTEXTの場合もあるので）、そして二つのサブシステム間の統合を比較的簡単にすることである。
担当者のつぶやき †
みんなの突っ込み †
