Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015)
ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。
こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。
この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもしれません。
ドメインモデルとは何か
とはいえ、まずは入口から始めましょう。私たちは1つの基本的な質問について再考しなければいけません：ドメインモデルとは何でしょうか？
ばかばかしい。ドメインモデルはドメインのモデルです。そうではありませんか？
具体的な例を用いて検討しましょう。バージョン管理システム（Version Control System: VCS）です。現在私たちは束にできるほどたくさんのVCSを持っていて、そのいずれもが他といくらか異なるモデルを提供しています。例えば、Subversionでは「コミット」は中央の（かつ単独の）リポジトリへのソースコードの変更の登録を意味するのに対して、Gitでは同じ言葉が分散された一群のリポジトリの特定のメンバーへのソースコードの変更の登録を意味します。「コミット」はそれぞれのVCSのユビキタス言語の語彙に含まれます。そして、そうであるなら、この語の意味のこうした違いは、その2つのVCSの基礎を成すドメインモデルの違いを反映しているのに他ならないでしょう。
この例から、これらの2つのモデル間の違いは、同一のドメインの問題を解決するためのアプローチの違いに由来することが分かります。ドメインモデルはドメイン自体のモデルではありません。そうではなく、実のところそれは、そのドメインのためのソリューションのモデルです。それぞれのVCSが誕生して初めて、それぞれのモデルが認識されるようになったのです。
このアイデアは全く単純明快です。別の例として、スプレッドシートソフトを見てみましょう。各種のスプレッドシートソフトは、シート、セル、数式、等々で構成される独特なドメインモデルを共有しています。このドメインモデルは VisiCalc とともに誕生し、その後進化してきたものです。私たちは会計の計算のためにスプレッドシートソフトを使うかもしれませんが、会計ドメインが、その歴史においてスプレッドシートの概念を持っていたわけではありません。そうではなく、スプレッドシートの概念やモデルは、幅広いドメインの問題を解決するために設計され、そのドメインが会計の一部をたまたま含んでいた、ということなのです。
2つのドメインモデル
伝統的に、ドメインモデルは、「分析モデル」と見られる傾向にあります。すなわち、設計ではなく分析の対象です。しかしながら、ドメインモデルはソリューションのモデルであるという私たちの新しいビジョンは、この見方に異議を唱えます。「ソリューション」が何であれ、それは私たちが設計するものです。折に触れて私たちが既存のソリューションの設計を分析するにしても。
「設計」は、以前に存在しなかったものを創造するのに対して、「分析」は、それがすでに存在する物事を扱うという点で、いくぶん受動的な言葉です。伝統的なOOアプローチにおいては、分析モデルは、既に存在し、当然の帰結として設計の対象ではない現実世界の抽象として見られる一方、私たちが（エンジニアとして）構築するソフトウェアの機能と構造を決定することを「設計」と呼ぶ傾向があります。エンジニアリング視点からは、この分割はとても自然にみえます。
ここでのポイントは、ドメイン駆動設計者の視点からは、「現実世界」は2つの下位要素―物理的な要素と情報の要素―を含むであろう、ということです。
物理的な世界にあっては、人々が働き、モノが動き、お金が稼がれます。それらは私たちが「ビジネス」という言葉によって想像するものです。ビジネスを進めるために、注文、請求、在庫記録、財務諸表、等々といった情報を私たちは記録し交換します。これは現実世界のもう1つの構成要素―情報処理―です。
したがって、ドメインモデルは2つの異なったモデルに分割されます。物理世界のモデルと情報のモデルです。
このような世界観のもとでは、物理世界のモデルはたいてい単に与えられ我々にとって制御できないものであるのに対して、情報のモデルの大部分は我々が設計し得る、と私たちは考えるでしょう。
2つのドメインモデルとOOA
DDD本において、エヴァンスは初期時点での表面的なモデルと深いモデルについて繰り返し語ります。コンテナ輸送アプリケーションからの彼の事例では、表面的なモデルが船舶（Ships）やコンテナ（Containers）のような物理的な実体を含んでいるのに対して、深いモデルは本船名／航海番号（Vessel Voyages）や船荷証券（Bills of Lading）（例えば p.191 「深いモデル」）のような抽象概念を含んでいます。これらのモデルの間の区別は、少なくとも部分的には「深さ」の違いによるのではなく、「対象」の違い、すなわち、対象が物理的なものか情報か、によるのです。
エヴァンスは、伝統的なOOAがこの区別を無視する様子に関して、示唆的な話を語ります。
新しいオブジェクトモデラがプロジェクトに参加すると、決まって最初に提案するものがあった。それが、あるはずのクラス、船舶とコンテナである。彼らが聡明でなかったわけではなく、ただ、深いモデルを発見するためのプロセスを経験していなかっただけなのだ。
（p.192）
2つのドメインモデルという着想に照らして、私たちは、これは「ただ、深いモデルを発見するためのプロセスを経験していなかっただけなのだ」ということだけによるのではなく、OOAの知識体系（または少なくともその一般的に受け入れられた理解）が物理的な世界のモデルと情報のモデルの区別を欠いているからであろう、と理解することができます。
しかしながら、この区別が無視されているといって驚くには当たりません。なぜなら、この2つのモデルの区別は常に明らかであるとは限らないからです。というのも、情報は、私たちの世界のあらゆる領域に浸潤してしまっており、あたかも物理的存在であるかのような顔をしてまかり通っているからです。小切手は物理的でしょうか？あるいは情報でしょうか？私たちはどのように真に物理的なものと小切手を区別するのでしょうか？あるいは、そもそも区別しなければならないのでしょうか？この点について私は明快な答えを持っていません。多くの場合、あなたは（まるでそれらが物理的であるかのように）情報モデルから安全に小切手を除外することができますが、その一方で、（紙幣、硬貨、小切手をひっくるめて呼ぶ）「現金有高（げんきんありだか）」をモデルに含めなければならないかもしれません。しかし、これは金科玉条ではありません。私たちは自身の判断力を用いなければなりません。とはいえ、物理的なモデルと情報のモデルの間に線を引くことは、依然としてモデリングにおける洞察をもたらすことができるでしょう。なぜなら、最終的に私たちがソフトウェアによって表現しなければならないものは、物理的なビジネスのモデルではなく情報のモデルだからです。
DDDの含意
ユビキタス言語とモデル駆動設計はDDDの中核を成す2つのプラクティスです。2つのドメインモデルに照らすと、ユビキタス言語は、物理的な世界のモデルから情報のモデルを切り離すための、そして後者を分析ではなく設計の対象とするための仕掛けとして理解することができるでしょう。それは、私たち開発者の領域を広げます。そしてモデル駆動設計は、ソフトウェアの構造が情報のモデルを正確に反映している状態を保ち続けることを私たちに要請します。それは、私たちの職業がアナリストと開発者に分解することを防ぎます。
かくして、情報モデルの設計は私たちの手の内にあります。私たちの情報技術の時代以前においてさえ、情報モデルは設計されてきました。複式簿記は、それらのモデルの注目に値する実例です。列車運行図表（ダイヤグラム）や楽譜はその他の例です。これらのモデルは、「ビジネス側」の人々によって設計されてきました（その頃「IT側」は存在しなかったので）。対照的に、私たちのIT時代において、情報モデルを設計する責任は宙に浮いているかのようです。私たちのITは、ビジネス側の人々にとってとても付き合いにくいものです。それゆえ、彼らは、ITを使って実装される情報モデルの設計にしばしば苦痛を感じさせられてきました。アナリストが設計の責任を担うべきなのかもしれません。しかし、彼らが行うのは設計ではなく分析です。その上、実装がもたらすであろうフィードバックを受けることができない中で設計するのは困難です（これもまたモデル駆動設計が重視する点です）。私たち開発者は、この責任を引き受けるベストな位置にいるのです。もちろん、ビジネス側の人々との緊密な協力関係を前提として。
ならば今、私たちの職業の本質的な営為のひとつは、ソフトウェア設計に裏打ちされた情報設計であるわけです。
これがDDDの含意です。
杉本 啓 @sugimoto_kei
経営管理基盤ソフトウェア fusion_place の、プログラマ兼設計者
http://www.fusions.co.jp