これまでの十四章
今日から数回に分けてコンテキスト同士を接続するパターンを読んでいきます。
共有カーネル
複数のコンテキスト間で、共有のモデルを持つパターン。モデルだけでなく、コード、関連するデータベース設計も含まれる。
Evansによると、まとまりのないチームが変換層と修復作業に時間がかかる場合、共有カーネルを使うことでうまくいくことがあると説明されています。
なんとなくネガティブなパターンのようにも見えますね。
共有カーネルの注意点
複数のコンテキストで共有する分、その維持には結構な労力がかかりそうです。
- 変更するには、両方のチームの合意が必要
- 稼働しているシステムは頻繁に統合する
- 両チームのテストが通ること
Evansも言っていますが、このパターンはコンテキスト内の他のモデルに比べて、変更が自由にできないことがわかります。
共有するのは、コアドメインのこともあるし、汎用サブドメインの場合もあるとのことですが、コアドメインを共有するのはちょっと辛みがありそう。
名前がついているのがとても大事
このようなパターンをこれからいくつか見ていくのですが、共有カーネルのようにちょっとネガティブなパターンも含まれています。
ただ、こういった接続をしているアプリケーションってありますよね。
DDDを採用している、していないに関わらず、システム間同士のやりとりというのは普通に行われていますし、そのやりとりの仕方というのは自然とこれらのパターン（パターン名を知っている、知らないに関わらず)を選択していると思います。
なかには理由が曖昧なまま接続していることもあるでしょう。
ここで、パターンを知り、パターン名を設計で使うことで、より明確な理由付けと明確な設計ができるようになるかと思います。
「このサブシステムとの連携は共有カーネルでは保守が大変そうですね。腐敗防止層で対応しましょう。」とか「APIをこちらから提供するので、顧客/供給者の関係でお願いします。」とか。
特にこれらのパターンは複数のチーム間で適用されるものなので、元々設計に慎重さが求めれるところだと思います。
パターンを明示的に適用することで、チーム間でのコミュニケーションがやりやすくなり、結論も出しやすくなるのではと思っています。