ドメイン駆動設計に出てくる概念モデルと分析モデルの違い

ドメイン駆動設計に出てくる概念モデルと分析モデルの違いについて、良い記事があったのでメモ。

【元ネタ】
ドメイン・フレームワークのススメ(第1回)

ドメイン・フレームワークのススメ(第2回)

【1】概念モデル、分析モデル、設計モデルを以下で定義している。
これは分かりやすい。

(引用開始)
概念モデル：問題領域に対する「理解のしやすさ」を重視したモデル。
実現手段の詳細によらない、問題領域の本質的な構造/特性を素直に表現したもの。

分析モデル：概念モデルをベースに、抽象化/一般化を加えてドメイン・フレームワークを分離/再構成したモデル。より広い範囲での再利用性/拡張性の向上を狙う。

設計モデル：分析モデルをベースに、特定のアーキテクチャ/ライブラリ/プログラミング言語等を想定して具体的な実現手段を組み込んで詳細化したモデル。
(引用終了)

ドメイン・フレームワークのススメ(第1回)では、Greedというゲームを概念モデルで描いている。
Greedというゲームの概念をそのままクラス図に落とし込んだだけのものが概念モデル。

つまり、概念モデルはAsIsモデルであり、あるべきモデル(ToBe)ではない。
だから、概念モデルに出てくるドメインを再利用するのは難しい。

あるべきモデル(ToBe)こそが分析モデル。
すなわち、概念モデルからドメインを抽出(蒸留)し、より抽象度を高めることで、仕様変更しやすくし、再利用を高める。

(引用開始)
概念モデルは対象領域(問題領域)の本質的な構造や特性を捉えて理解を深めるために有効です。
この段階では、実現手段(HOW)の詳細にとらわれず、そもそも「どんなもの(WHAT)を相手にしなければならないのか」を整理しながら理解を深めることに注力します。システム開発の早い段階で問題領域に対する理解をしっかり深めておくことは、後のさまざまな工程に良い影響をもたらします。
そのため、概念モデルは「理解のしやすさ」を最も重視して作成されます。
一方で、概念モデルは現在対象となっている世界「そのままの姿」を素直に捉えたモデルであるため、基本的に抽象化/一般化や類似の問題領域に対する再利用性や拡張性の考慮などは薄くなります。
(中略)
ドメイン・フレームワーク化されていない概念モデルをベースに(概念モデルを「分析モデル」と呼んで)、設計、実装…といった詳細化の工程に進んで行ってしまう開発プロジェクトも多く見かけます。
この場合、大きな問題が無ければそれなりの期間/工数で正しく動作するシステムが出来上がってしまうので、一見するとその開発プロジェクトは成功したかのように思えてしまうのですが、そのようにして作られたモジュール群は後に類似の問題領域の別システムの開発のために流用(再利用)してみようとしてもあまり上手くいきません。
再利用性や拡張性が活かせないのであれば、オブジェクト指向で開発する意義の半分ほどを失うと言ってもオーバーではないでしょう。
オブジェクト指向は魔法ではないので、単に「クラス」という単位でモジュールをまとめれば自然に再利用性や拡張性が上がる…というわけではないのです。
(引用終了)

ドメイン・フレームワークのススメ(第2回)では、Greedゲームを抽象化したゲームの分析モデルを提示している。
ゲームの分析モデルでは、「ゲームフレームワーク」というパッケージにドメインモデルがパッケージングされて、再利用できるコンポーネントになっている。
そして、「ゲームフレームワーク」を継承することで、Greedゲームを実装できるように設計されている。

つまり、ドメインモデルという分析モデルへ蒸留させたことで、ドメインの再利用性が高まった利点がある。
しかし、分析モデルにも欠点はある。
分析モデルは抽象化しすぎるために、理解しにくいのだ。

(引用開始)
Greedゲームの分析モデルでは、Greedゲームに限らず他のゲームにも適用可能な部分(ドメイン・フレームワーク部分)とGreedゲーム固有の都合に左右される具象部分とが、モジュール(クラス)としても明確に分離/整理されています。
そのため、このようなモデルをベースに設計/実装されるソース・コードのうち、少なくともドメイン・フレームワーク部分については他のゲームを実装する場合にもそのまま再利用できる可能性が高くなります。
まとめ方(抽象化や一般化の方法)を工夫してなるべく多くの部分をドメイン・フレームワークとして抽出できれば、それだけ再利用率を上げることができるでしょう。
一方で、抽象化/一般化による変形/分離が施された分析モデルはある意味「素直な構造」ではなくなっているので、「問題領域の構造/特性を理解する」という目的にはあまり向いていない(理解するのが難しい)モデルになります。
たとえば、図 2 に示した分析モデルだけを見て、Greedゲームが「ゲーム」「ラウンド」「ターン」「ロール」の階層構造を持つということをパッと読み切るのは困難です。
ドメイン・フレームワーク化はドメイン・レベルでの再利用性/拡張性を確保するために必要なのですが、抽象化/一般化と理解のしやすさはトレードオフの関係にあります。
新たにモデルを見る人がそもそもの問題領域を素直に理解できるように、分析モデルの元になった概念モデルも対にして残しておく(抽象度の異なる目的別のモデルを作成する)のが良いでしょう。
(引用終了)

【2】上記のドメインフレームワークの考え方は、概念モデル(AsIs)→分析モデル(ToBe)へ蒸留させていくやり方だが、同じような経験がRedmineのワークフロー抽出にもある。

ある現場にRedmineを導入するとしよう。
すると、まず真っ先に行うのは、メンバー全員からヒヤリングして、その現場の現状のワークフローを抽出することだ。
抽出されたワークフローがRedmineのトラッカーの候補になる。
この作業は、あるべきワークフローではなく、現状運用されているワークフローなので、概念モデル(AsIs)と同等だ。

しかし、現状運用されているワークフロー(AsIs)があるべきワークフロー(ToBe)とは限らない。
無駄なステータスがあるかもしれないし、本来は別のワークフローで厳格に運用すべきかもしれない。

だから、あるべきワークフローのイメージを描いて、Redmineのワークフローを決定し、Redmineのトラッカーに登録する。
この作業は、現状のワークフローをモデルチェンジしてあるべきワークフローへ変えたので、分析モデル(ToBe)と同等になる。

【3】そんなことを考えると、設計という作業は、あるべき姿(ToBe)をイメージするのが重要であり、ドメイン駆動設計は進化的設計(反復的設計)によってAsIsからToBeを導き出そうとする手法であると思える。
最初から、正しいモデルを描くのではなく、リファクタリングしながら、より良いモデルへブラッシュアップしていく。
そのための技法やノウハウが「ドメイン駆動設計」にたくさん埋め込まれているわけだ。

色々考えてみる。

【追記】確かに、ドメイン駆動設計では、モデルとソースコードは一致するから、分析モデルと概念モデルの間に違いはない。

Twitter / j5ik2o: ドメインという言葉があるからといってすぐにDDDと紐づけて考えるのはよくない。DDDでは分析と概念のモデルは分けて考えないので。要注意。 / “ドメイン駆動設計に出てくる概念モデルと分析モデルの違い: プログラマの思索” http://htn.to/tXUEvR

でも、「ドメイン駆動設計」には、「浅いモデル」「深いモデル」という区別が出てくる。
おそらく、「浅いモデル」は「概念モデル」、「深いモデル」は「分析モデル」を示しているのだろうと思う。

プログラマが「モデルのあるべき姿」をいち早く理解できれば、単純に現状の業務を写しただけの概念モデルではなく、より汎用性の高い分析モデルをあまり苦労せずに作ることもできるだろう。
例えば、「ドメイン駆動設計」の貨物輸送モデルに出てくる船荷証券、利息計算モデルに出てくる発生主義会計（経過勘定科目）について業務知識をプログラマが持っていれば、業務の専門家と議論しているうちに、その存在に気づけるだろう。