DDDの境界付けられたコンテキストについて調べてみた

エリック・エヴァンスのDDDの14章.“モデルの整合性を維持する"を読んでみたのでそのメモなど

戦略的設計

戦略的設計の原則は設計上の意思決定を導いて、各部分の相互依存関係を減らし、設計をより明確にしながら、蹴って的に重要の相互運用性と相乗効果を失わないようにするものである。
そのためには境界付けられたこんんテキストを定義してモデルの適用範囲を内部に限定したり、蒸留によって混ざりってしまったコンポーネントを分離したり、システム全体に対して統一感を持たせたりして、ドメイン駆動設計ではこれを戦略的設計として表される。

モデルの整合性を維持する

システムを一つのモデルで統一することは以下のリスクがある。 - 1.一度にあまりにも多くのレガシーシステムを置き換えようとしてしまうかもしれない. - 2.調整にかかるオーバーヘッドが能力の限界を超えてしまうために、巨大なプロジェクトは動きが取れなくなってしまうかもしれない。 - 3.特殊の要件を伴うアプリケーションは、その要求を完全には満たしていないモデルを使わなければならないかもしれず、そのせいで振る舞いをどこか別の場所に入れなければならなくなる。 - 4.逆に単一のモデルを使って万人を満足させようとすれば選択肢が複雑になり、モデルを使うのが難しくなる。

モデルについてどこを共通して使うか、それとも分けて使うかというのは常に認識を合わせておなければ混乱や破損が生じる原因となる、認識を合わせるためにも境界付けられたコンテキストで各モデルの適用範囲を定義し、コンテキストマップによってプロジェクト全体のコンテキストとコンテキスト間の関係を可視化させておきたい。

境界付けられたコンテキスト

似たようなモデルであっても使用するコンテキストによって動きが変わってくることもあるし、それを境界付けることもなく使用していたらバグの温床となりうる。そうならないためにもモデルをどのコンテキスト内で使用すべきなのかをはっきりとさせておく必要がある。

継続的な統合

コンテキストやモデルの粒度にブレがないように継続的にコミュニケーションをとって認識合わせをしておかなければならない。

コンテキストマップ

境界付けたコンテキストを見える化してそれぞれのコンテキスト、モデルに対して名前を付けることでそれがユビキタス言語として使えるようになる。コンテキストマップを作成することで問題が起きた時の修正箇所は明白にすることができる。

境界付けられたコンテキスト間の関係

境界付けられたコンテキスト間でやり取りをする場合には以下のような方法がある。 - 共有カーネルを利用する - 顧客/供給者の関係で利用する - レガシーシステムとかの連携でも使われる腐敗防止層を使う - 外部サービスとの連携であれば公開ホストサービスを利用する

共有カーネル

境界付けられたコンテキスト間で共有して使いたいモデルがある場合は、コンテキスト毎にモデルを作成するのではなく一つのモデルをコンテキスト間で共有させて方が良い場合もある。目標は重複を減らして2つのサブシステム間の統合を容易にすることである。

 顧客/供給者の開発チーム

コンテキスト毎で顧客/供給者といった下流、上流の関係をはっきりとさせておく。期待されるインターフェースは検証を行い下流への副作用を心配せずに上流チームが自由に変更を行えるようにする。参照だけするのと、登録・更新、削除、参照ができるのを分けるということか。

腐敗防止層

レガシープロジェクトのモデルに対して機能追加するときなどでは、新システムと旧システムの橋渡しとして使われる腐敗防止層がある。コンテキスト間でも同様に腐敗防止層をインタフェースとして利用することで別コンテキストの機能を利用する際に気をつけなければいけないことを隠蔽することができる。

公開ホストサービス

一つのコンテキスト内のモデルを複数のコンテキストで利用することが考えれる場合は公開ホストサービスとして他コンテキストから利用できるようにする。