「ドメイン駆動設計」とは
要件定義や仕様書に沿ってソフトウェアを開発しても、出来上がったシステムを使い始めた現場の利用者から「新しいシステム、使いづらい」「大金をかけて使えないシステムをつくっている」と言われることは珍しくない。なぜ、こういう事態に陥ってしまうのか。成瀬氏が問題提議するのは、従来型のソフトウェア開発工程における、致命的な断絶の存在だ。
従来型のソフトウェア開発では、一般に、プロジェクトマネージャーとクライアント（プロダクトオーナー、ステークホルダーなど）の打ち合わせで出来上がった仕様を開発者がコードに落とし込む。そして、出来上がったものが実際にソフトウェアを利用する人のもとに送られる。何をつくるのか、目指すものを決める段階で利用者の存在がない。その結果、「開発者がどれだけ苦労してつくったとしても、それが利用者の欲しいものではない」ということになってしまう。
こうした不幸をなくすための手法の1つがドメイン駆動設計だ。ドメイン駆動設計の「ドメイン」とはソフトウェア利用者が生きる世界であり、そのソフトウェアを適用して解決しようとしている対象領域のことを指す。ここで重要なのは「ドメインに何が含まれるか」ということ。例えば、「物流」というドメインには船やトラック、飛行機、コンテナ、燃料といったものがある。それらの機能を的確に捉え、コードに落とし込むことによって、そのソフトウェアは真にドメインの利用者のためにつくられたものになると言う。
個々の業界に特有のリアルなものや概念をコードにする。言葉にすると当たり前なのだが、実は非常に難しい。開発者にはドメインの知識がないし、利用者はドメインの事物をコードにすることはできないからだ。この「ソフトウェアを適用する対象領域」と「コード」をいかにして地続きにするか。そのためのプラクティスがドメイン駆動設計なのだ。
ドメイン駆動設計の構成は大きく「モデリング」と「パターン」の2つに分けられる。ドメインの世界の事物（特徴、機能）をモデル化するモデリング、そしてモデルをコードに落とし込むパターンだ。
まず、先ほどの図のドメイン（物流）の中に含まれていたトラックを例に考えてみよう。トラックの機能として、例えば「アクセルペダルを踏むと進む」「荷物を運べる」があるとする。このとき物流システムでは、おそらく「荷物を運べる」ことのほうが重要だろう。しかし、例えばレーシングゲームなら重要なのは「アクセルペダルを踏むと進む」ことかもしれない。このように、このトラックだけとって見ても、どの機能が重要かはソフトウェアが使われるドメインによって変わってくる。
「荷物を運べる」という、このドメインにとって重要な知識を抽出（抽象化）する。この作業がモデリングで、ドメイン駆動設計においては「ドメインモデリング」と呼ばれる工程だ。そして、抽象化して出来上がったモデルが「ドメインモデル」。
もちろん、ドメインの事物をすべてドメインモデルに置き換えたらそれで終わりではなく、最終的にはコードにしなければならない。目的はドメインにとって重要な知識を抽出し、抽象化した知識を役に立つ形にすること。このコードのことを「ドメインオブジェクト」と言い、知識をコードで表現するやり方をまとめたものがパターンということになる。
こうすることで、ドメインで起こる変化、例えばトラックの捉え方が変わってこのシステムでは燃費が最重要だとなったとき、ドメインモデルを修正し入れ替えれば、その変化がモデルを通じてコードに伝わることになる。モデルを媒介にドメインとコードが結びつくことによって、結果として、ソフトウェアの利用者の世界とコードが寄り添って、乖離することはなくなる。
