ドメイン駆動設計のガイドライン: Capture - Embed - Protect

ソフトウェア設計と開発のガイドラインとしてドメイン駆動設計(DDD)の中核的な哲学とプラクティスを用いる場合、それはCapture — Embed — Protectという３つの原則にまとめることができる — 今年のDDD eXchangeカンファレンスで行なったプレゼンテーションの中で、Steven A. Lowe氏はこのように主張した。我々は、肯定的な行動を取るに十分な理解を得ることでドメインモデルを捕捉(Capture)し、コードや会話の中にそれを埋め込み{Embed)、他ドメイン、特に技術的なドメインによる改変から保護する(Protect)のだ。

ThoughtworksのプリンシパルコンサルタントであるLowe氏にとってDDDの出現は、企業データモデルへの誤った執着を打破し、ドメインを重視した自己完結型の重複モデルに置き換えるという意味において、まさに画期的なものだった。特に氏が強調するのは、DDDがソフトウェア開発の重点と範囲を、それまでの技術的観点から、ビジネス目標に基づく探索と解決に変えた点だ。一方でDDDはいまだいくつかの“神話”に苛まれているが、れらはすべて誤りだと氏は考えている。

• DDDは難しい？そんなことはない。集中と自己規律は必要だが、それはプログラミングも同じだ。
• DDDはオーバーヘッドを発生させる？それはドメインについて学ぶことが不要だと思っている場合にのみ言えることだ。
• DDDは複雑なドメインのためのもの？最も必要なのはそうかも知れないが、考え方はすべてにおいて適応可能だ。

Captureの目標は、ドメインのメンタルモデルを可視化および双方向化することによって、誰もが同意できるものにすることにある。Lowe氏が推奨するモデル構築方法は、関係者全員をひとつの部屋に集めてドメイン内のイベントに集中させる、というものだ。これはイベントストーミング(Event Storming)と呼ばれるテクニックで、Albert Brandolini氏が開発したグループモデリングのアプローチである。Lowe氏はこれが極めてパワフルで、最小の努力で学習スピードを最大化する方法であることを見出したのだ。

ドメインモデルをコードにEmbedする場合に重要なものとしては、ドメインの意図を反映したネーミングを行なうこと、ドメインの振る舞いを反映するような構成にすること、この２つがあげられる。適切なネーミングが思い浮かばないのであれば、その対象を充分に理解できていないということなのだ、とLowe氏は述べている。ドキュメントや図表は更新が遅れている場合もあるので、コードは信頼できる唯一の真実の源なのだ。ドメインモデルをコードに組み込むことで、モデルは常に正しく、開発者が利用できるものとなる。上位レベルにおいては、ドメイン専門家がコードを読んで理解することも可能になる。

ドメインを改変から保護(Protect)するためには、バウンダリを使用してサブドメイン同士を分離する。コンテキストのバウンダリはそのインターフェースであり、コマンドやイベントが出入りする。バウンダリの強度も重要だ — そのインターフェースでは、どのような検証と変換が行われるのか？具体的な実現策としては、モジュールを使用してサブドメインを物理的に分離する方法が、そのメリットとしては、コードベースの結合度の低下とレジリエンスの向上などがあげられる。これに関してLowe氏は、後になって技術的負債を取り除くよりも、最初からそれをコード化しない方が簡単だ、と述べている。

Capture — Embed — Protectは各ステップを複数回実行する反復プロセスであり、検証済みの小規模なモデルからドメインモデルを段階的に構築するものであることを強調して、Lowe氏は自身の講演を結んだ。さらに氏はドメイン駆動設計を普遍的なものにすることの重要性にも触れ、ドメインを意図的にモデリングしなければ、意図しない他のものをモデル化することになる、と述べた。