DDD連載記事
なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか
モデルでドメイン知識を表現するとは何か
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か
ドメイン駆動 + オニオンアーキテクチャ概略
はじめに
ドメイン駆動設計における「モデル」の捉え方の話と、境界付けられたコンテキストの必要性の話をします。
「境界付けられたコンテキスト」というものはドメイン駆動設計の上で非常に重要ですが理解しにくいポイントなので、その必要性と定義を理解しやすいように書こうと思います。
モデルとは？
ソフトウェア開発において「モデル」「モデリング」という単語はよく聞きますが、定義について立ち止まって考えたことがない人もいるのではないでしょうか。
日本語で定義をググってみると、UMLの文脈で話題になることが多いようです。抽象的な単語なので定義は様々だと思いますが、日経コンピュータの記事の定義を引用してみます。
業務の流れやシステム構造といった、目に見えないものを可視化するためのシステム構築技法。
記号を使って平面図（モデル）を作成する。
目に見えないものを 可視化する のがモデルと書いてあります。
これもある文脈では正しいと思いますが、ドメイン駆動でモデリングをしていく際には、少し捉え方を注意した方が良いことがあります。
モデリング = 現実世界のものを正しく表現するものではない
ということです。
Eric Evansの定義
Eric EvansのDDD Referenceを見てみましょう。
(こちらの資料が何かはドメイン駆動設計の定義についてEric Evansはなんと言っているのかの記事に書きました)
model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain 対象領域の特定の側面を表現し、関連する問題を解決するために使用する抽象物
重要なことは、
モデルが表現するのは 特定の側面(selected aspects) であり、
目的にあるのは 関連する問題を解決する ということなのです。
特定の事象について抽象化するということは、いろいろな具体的な物事をそぎ落としているので、「正確に描写することは不可能である」というのが前提になります。では正確さを目指さずに何を目指すのか？
それは 問題解決という目的に合致するかどうか です。
これは"可視化する"とは少しニュアンスに違いがあると思います。
事例
例として、Domain Driven Design(en.wikipedia)の中でEntityとValueObjectの違いについてこのような記述があります。(Entity、ValueObjectの定義については後々記事を書く予定です)
Example:
Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context.
However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object. ほとんどの航空会社はすべての便で一意に各座席を区別します。この文脈では、各座席はEntityとなります。
しかし、Southwest Airlines、EasyJet、Ryanairはすべての座席を区別せず、すべての座席は同じです。この文脈では、座席はValue Objectといえるでしょう。
飛行機の座席というものをただ「可視化」するのであれば、座席は座席なので、同じモデルになるはずです。
しかし、この事例では物理的には同じものが、運営会社のサービス方針によってモデルとしての認識が分かれたのです。
これはつまり、それぞれの問題解決の文脈によって、フォーカスする側面が変わり、定義されたモデルが変わったということです。
モデルを適用する範囲を限定する
航空会社によってモデルの認識が異なることがあることがわかりました。では、同じ航空会社の中では常にモデルは統一されているのでしょうか？
少し想像するだけでも、「座席」を物理的に作るチームと、「座席」の予約管理をするチームでは「座席」の問題を解決するための捉え方は違いそうです。
モデルの認識が同じ範囲は世界共通ではあり得ない、会社単位でもない、だとすると部署？チーム？そもそも人によって違うもの・・・？
こう考えていくと、 モデルを適用する範囲を明示的に定義する必要がある という結論になるかと思います。この明示的な境界付けを、ドメイン駆動設計の用語では 境界付けられたコンテキスト(bounded context) と呼びます。
Eric EvansのDDD Referenceの定義を参照します。
bounded context: A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
境界付けられたコンテキスト:
特定のモデルが定義され適用される境界（通常はサブシステム、または特定のチームの作業）に関する記述
ドメイン駆動設計では、この境界付けられたコンテキストというものを非常に重要視します。前述の通り、この境界を設けないことには、何のモデルも正しく定義できないからです。
そして、コンテキスト同士がどういう関係性を持つのかを定義します。その成果物をコンテキストマップと呼びます。これがドメイン駆動設計における設計の一番のベースになります。
まとめ
言葉の認識合わせとしてのモデルについて定義し、DDDのわかりづらいワード境界付けられたコンテキストについて説明しました。
今後は境界付けられたコンテキストがどのように実装に落とし込まれていくのか？を書いていきたいと思います。
また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。
重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコードをふんだんに盛り込みました。現場で実践して、困っていることがある方はぜひこちらもご覧ください。
現場での導入で困ったら
DDDを導入しようとすると結構試行錯誤に時間がかかります。
現場で導入してすぐに効果を発揮したい！！という方向けに、基礎解説とライブモデリング/コーディングを行う勉強会の開催や、設計相談を受付ております。
事例紹介もあるのでご関心あれば覗いてみてください。開催形式は柔軟に対応できるのでお気軽にご相談ください。
