ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り

エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。
@sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。
ラフなメモ書き。

【元ネタ】
ドメイン駆動設計: プログラマの思索

ドメイン駆動設計よりもパターン本が好き: プログラマの思索

ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索

DOAとOOAの違い: プログラマの思索

Agile開発に足りないもの～モデリング技術: プログラマの思索

ドメイン駆動設計の本の違和感は二つある。
一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。
もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。

前者は、「ドメイン駆動設計」というタイトル通り「ドメイン分析」の内容ではない。
第1・２部では、アナリシスパターンに似たパターンを解説して、第３部ではモデルの揺さぶり、第４部はソフトウェアプロダクトラインに似たチームによるモデリングと戦略などを解説している。
つまり、解説の対象は業務分析ではなく、オブジェクト指向設計が対象になっている。

普通は、分析と設計は本質的に違う。
特に業務分析では、顧客が自分の業務で抱える問題点に対して、何らかのソリューションを提供するために、現実の業務を分析した後、あるべき業務の姿を定義して、業務システムのモデルを作る。
これが分析モデルであり、普通は、AsIsモデルを作った後に、実現可能性(フィージビリティ)やコスト、納期、顧客の要求などを加味して、ToBeモデル(分析モデル)を確定する。
その後、分析モデルは詳細化されて設計モデルとなり、実装工程に入っていく。

IPAが定義したITSSスキルモデルでは、分析工程はITストラテジスト、設計工程はITアーキテクトが担当するわけで、分析と設計は作業内容もロールも異なる。
この手法は典型的なWF型開発の分析・設計技法だ。
だから、外部設計・内部設計という言葉で作業や工程を使い分ける。

そもそも「ドメイン」という概念は分析すべきものであるのが普通だ。
実際の用語としても「ドメイン設計」よりも「ドメイン分析」の言葉のほうを多用するからだ。

だが、ドメイン駆動設計では、設計モデルを開発者がドメインエキスパート(業務の専門家)と一緒に何度も洗練させていくと、分析モデルになっていくと言う。
第３部の191ページに「深いモデル」「浅いモデル」という言葉が出てくる。
Agile開発に足りないもの～モデリング技術: プログラマの思索で@sugimoto_keiさんは、浅いモデルはビジネスモデル、深いモデルは帳簿モデルと呼んで区別されていたが、上記の考え方に従えば、深いモデルは分析モデル、浅いモデルは設計モデルに相当する。
つまり、開発者がシステムを実装対象として捉える場合は設計モデルという浅いモデルであり、顧客やアーキテクトがシステムを抽象化した本質的なモデルとして捉える場合は分析モデルに相当するわけだ。

そして、設計モデルから分析モデルへモデルが変化するタイミングは、第8章の「ブレイクスルー」と呼ばれる。
つまり、開発者が設計モデルを作っている最中はまだ本質的な概念を見いだせていないが、そこから本質的な概念を見出してモデルをより汎用的・抽象的な分析モデルに変換できた時を指すわけだ。

実際、第3部では、設計モデルから分析モデルへ変換できた例として、貨物輸送システムと利息計算サービスの2つの例が出てくる。
貨物輸送システムのモデルでは、荷物の物流が本質的な問題(ドメイン)ではなく、荷物の権利(つまり船荷証券という勘定科目)が本質的な概念に相当し、それがオブジェクトとしてモデルに自然に出てくる。
また、利息計算サービスでは、単なる利息の計算式が本質的な問題ではなく、発生主義会計(つまり、前払保険料、未払利息などの経過勘定科目)の概念がモデルに自然に出てきて、モデルがより抽象的に整理される。
すなわち、ドメインという本質的な概念がモデルのオブジェクトとして現れたタイミングが、設計モデルから分析モデルへ変わったブレークスルーというわけだ。

後者としては、ドメイン駆動設計では分析と設計を一体化することに特徴があり、要件定義から設計に至る上流工程を全て一つの作業にまとめてしまうこと。
過去のオブジェクト指向設計では、業務分析した業務をユースケース図で洗い出し、そのユースケースから概念モデルを作り、実装に近い設計モデルへ詳細化してプログラムになっていくので、分析と設計を明確に分けていたように思う。
実際、概念モデルの粒度はとても荒くて設計モデルへ詳細化しなければ、実装できない。

オブジェクト指向設計の最大の利点は、要件定義から分析、設計、実装までオブジェクト指向の観点で一気通貫で作れる点にあると言われてきた。
しかし、たとえオブジェクト指向設計であっても、実際のソフトウェア開発では、分析モデル、そして実際のプログラムはどんどん乖離していく。
分析モデルをいくら頑張って作っても、実際に作ってみると、システムとして実現するには仕様そのものに矛盾がある場合は多く、開発工程で妥協して作る時が多い。
そしてリリース時には、当初の分析モデルとは微妙に違ったシステムとして完成して、実際の運用に入っていく。
つまり、分析モデルから実際に運用されいているプログラムまでのトレーサビリティを担保するのは実際はとても難しい。
作ってみて初めて顧客が想像していた仕様とプログラムが異なるのはよくあることだ。

だが、ドメイン駆動設計では分析モデルと設計モデルは同じ工程で作るべきものであり、一体化しているので、プログラムにとても近いから、モデルとプログラムにさほどの差は出てこない想定になっているのが利点の一つだろう。
つまり、ドメイン駆動設計は、本来のオブジェクト指向設計の先祖返りとも言える。

そして、ドメイン駆動設計がやりやすいシステム開発の対象は、プロダクトアウト指向よりもマーケットイン指向の製品開発やサービス開発だろう。
つまり、実装前にきちんとした仕様が確定しているプロダクトアウト指向の開発ではなく、マーケットにいち早くサービスや製品を投入しながら、売れ行きに応じて機能を変えていくマーケットイン指向の開発の方が向いている。
実際、マーケットイン指向の開発では、分析モデルは実装前に確定しているわけではないから、プログラミングしながら分析モデルもブラッシュアップせざるを得ない。
例えば、変化の激しいWebサービスやスマートフォンのようなVerUpの激しい製品の開発にドメイン駆動設計が向いていると言えるのかもしれない。
だから、設計を重視するアジャイル開発者がドメイン駆動設計に注目しているのだろう。

でも、僕の感想としては、ドメイン駆動設計をいきなり勉強するよりも、オブジェクト指向設計(OOA)やDOAを習得した後に手を出す方が理解しやすいと思う。
実際、ドメイン駆動設計に出てくるパターンは、アナリシスパターンや実践UMLに出てくるパターンに似ているからだ。
例えば、勘定パターンはアナリシスパターンにあるし、腐敗防止層は実践UMLのファサードパターン(純粋架空物：Pure Fabrication, 間接化：Indirection)そのものだ。

また、設計モデルから分析モデルへ抽象化していく場合、業務知識がなければ変換できないだろう。
僕が見聞きした限り、DOAの設計者は会計システムや生産管理に詳しい人が多いが、彼らは実際の業務経験が豊富なため、分析モデルを設計モデルに詳細化できるし、設計モデルから分析モデルへ抽象化していくこともできる。
特に日本では、業務システム開発とDOAを組み合わせた歴史があるので、業務分析と設計をミックスした手法がたくさんある。
例えば、日本のDOAには、渡辺さんが提唱するDOA、T字型ER、TH法など各種の流派がたくさんある。

大半のDOAの設計者は業務経験が深いがゆえに、分析モデルと設計モデルの違いやモデリングの技法についてたくさんのノウハウは持っているので、ドメイン駆動設計に書かれているモデルの意味は理解しやすいだろうと思う。

とは言え、ドメイン駆動設計に書かれている分析モデルの例はとても実用的で面白いし、理解できれば実際の仕事にも役立つだろうと思う。

【追記1】
個人的には、第３部が一番面白いと思う。
第１～２部はアナリシスパターンや実践UMLなどに出てくるパターンの焼き直しに過ぎない。
第３部は、設計モデルから分析モデルへ質的に変換する事例が出てくるので、この本の一番の見所だと思う。
第４部は、ソフトウェアプロダクトラインに似たモデリングプロセスの解説のような感想を持った。
「蒸留」という概念は、SPLで言うコア資産の抽出プロセスに似ている。
チームによるモデリング戦略は、アーキテクチャやモデルは組織構造に依存しているというConwayの法則の焼き直しのように思える。

【追記2】
関西でドメイン駆動設計のセミナーが6月にあります。
アジャイル開発で設計や業務分析に悩んでいる人、オブジェクト指向設計をもっと勉強したい人にはお勧めです。

第47回 SEA関西プロセス分科会-SEA関西

6月23日 第47回 SEA関西プロセス分科会(大阪府)

日々精進 - スパークスシステムズ ジャパン代表のBlog:セミナー情報2点 - livedoor Blog（ブログ）