ドメイン駆動設計に出てくる「モデル」とは何ですか？～第28回関西IT勉強宴会の感想

第28回関西IT勉強宴会でドメイン駆動設計の講演を聞いてきた。
講演よりも1時間の質疑応答の方がとても参考になった。
ラフなメモ書き。

【元ネタ】
第28回　関西IT勉強宴会 : ATND

関西ＩＴ勉強宴会のブログです: 2013-12-13（金）第28回関西IT勉強宴会　ドメイン駆動設計を知ろう

ドメイン駆動設計を知ろう(発表資料)

ドメイン駆動設計入門 - Digital Romanticism

ドメイン駆動設計の意義～MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築: プログラマの思索

ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索

SNSチームでのドメイン駆動設計の実践 | GREE Engineers' Blog

第53回 SEA関西プロセス分科会「ぐるぐるDDD/Scrum – モデリングと実装のうずまきをまわそう」-SEA関西

ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 -: ソフトウェアさかば

【1】質疑応答は1時間ずっと続いたが、詰まる所「ドメイン駆動設計に出てくる「モデル」とは何ですか？」という質問に対して、延々と議論していただけだったように思う。

主催者の佐野さんから、ドメイン駆動設計に出てくるモデルは、WF型開発における外部設計または基本設計で出てくるモデルのように思えるが、そのモデルは分析モデルなのでソースコードではないから違うように思える、と質問があった。

ドメイン駆動設計では、モデルはソースコードで表現できるものと一致するので、コーディングできないモデルは含まれない。
つまり、ドメイン駆動設計のモデルは、システム化可能なモデルなのだ。

しかし、WF型開発であろうが、普通のシステム提案では、業務フローのうちシステム化する部分と従来の手運用の部分を分けて、システム開発の対象を絞る。
その段階のモデルには、帳票ベース、電話ベースの業務フローが含まれるので、システム化対象ではない。
なぜシステム化対象でないモデルも作るのか、という理由は、システムではなく、顧客の経営者の観点で、業務フローはどうあるべきか、を考えたいからだ。
だから、佐野さんの違和感はとても納得できる。

また、渡辺さんから、設計者としてのモデラーが見るモデルはどれか？という質問があった。
そこで僕が質問して、ドメイン駆動設計に出てくるドメインモデルは、渡辺式3要素分析法における機能構成ではないか。システム化されていない業務はドメイン駆動設計の範囲外ではないか、と話した。

渡辺式3要素分析法では、業務システムは、業務構成・機能構成・データ構成の3つの観点で作られる。
業務構成は業務マニュアルそのもので、ユーザ側から見たシステムのユーザインターフェイス層に相当する。
機能構成はプログラムそのもので、ドメイン駆動設計のアプリケーション層やドメイン層に相当する。
データ構成はデータ格納庫であり、ドメイン駆動設計のインフラストラクチャ層に相当する。
第28回　関西IT勉強宴会 : ATNDで佐野さんが説明されている通り、上記のようにDOAとドメイン駆動設計を対比させると分かりやすいと思う。

杉本さんからも、ドメイン駆動設計に出てくるモデルは実装モデルにすぎないのではないか、業務フローを分析するユーザの観点の分析モデルと開発者視点の実装モデルは一致しないのではないか、という質問があった。

お二人の意図は、ドメイン駆動設計に出てくるモデルは開発者視点の実装モデルにすぎないのではないか、だとすればユーザ観点の分析モデルとは一致しない。
すると、ドメイン駆動設計に出てくるドメイン(業務)はどのレベルでどのように説明しているのか、という内容だと推測する。

3人の方の話を聞くと、DOAの観点のモデルはユーザ観点の分析モデルであり、ドメイン駆動設計に出てくる実装モデルとは違う、と感じた。
だから、ずっと話が噛み合っていないから延々と議論していたのだと思う。

【2】これらの質問に対して、@sakaba37さんから、ドメイン駆動設計にもプロセスを含むのですね。
以前、原田騎郎さんのScrum＋DDDの講演では、ドメイン駆動設計はインクリメンタルなプロセスでモデルを設計していくと聞いた。
つまり、ユーザ観点で最小の価値を実現する実装可能なモデルをコアとして作り、そこからモデルの境界を広げていく、と。

その話の観点では、ドメイン駆動設計のモデルは実装モデルを起点として作られるが、MVP(必要最低限の価値を持つ製品)から出発し、あるべきモデル、つまり分析モデルへ発展していくプロセスがドメイン駆動設計である、と理解することができる。
その実装モデルが分析モデルのレベルに到達した時、あるいは分析モデルと同等になった時が、ドメイン駆動設計に出てくる「ブレイクスルー」に一致するのだろうと思う。

つまり、ドメイン駆動設計では、分析モデルは作られるべき対象ではなく、実装モデルから発展した対象である、と理解できると思う。
その観点では、WF型開発の要件定義やシステム提案とは全く違う。

ドメイン駆動設計がそのようなモデルを必要として作られた背景としては、WebサービスやSNS、ゲームのように、最初から完璧に近いシステムを作るのではなく、最低限の機能を持つシステムを最初に作り、そこから少しずつ機能拡張していく状況にマッチしていることがあげられるだろう。

すると、ドメイン駆動設計を適用しやすい対象としては、ミッションクリティカルな基幹系業務システムや組み込みシステムではなく、スタートアップ企業のシステム開発の方が向いているのだろう。

【3】他に、UMLを使ったオブジェクト指向設計(OOA)とドメイン駆動設計は何が違うのか、という質問もあった。
確かに、ドメイン駆動設計はオブジェクト指向をベースとしており、何が違うのか、分かりにくい。

この質問に対しては、講演者から、ドメイン駆動設計はフレームワークのようにある程度、型が決まった手法であるのに対し、OOAはたくさんのやり方がある点が違う、と回答があった。

例えば、OOAの典型的な手法としては、ユースケースから概念モデルという分析モデルを作り、そこから実装モデルへ詳細化したら、ソースコードを自動生成してシステムを作っていくというモデル駆動開発(MDA)がある。
その観点では、コードと一体化した実装モデルの範囲や品質をイテレーティブに広げていくドメイン駆動設計と、分析モデルから作られる実装モデル(クラス図)を元にソースを自動生成して、設計から開発まで一気通貫で作るモデル駆動開発は全く違う。

【4】@sakaba37さんから、ドメイン駆動設計に出てくるユビキタス言語は、構造化設計で言うデータディクショナリと同じですか？という質問があった。
この質問に対して、講演者から、ユビキタス言語はデータだけでなく操作も含むので、データディクショナリ＋αですね、と回答があった。

また、ユースケースはドメイン駆動設計に出てくるアプリケーション層に含まれるのか？と質問したら、講演者から、それは違う。ユースケースはドメイン層に含まれる。
エヴァンズは、ファウラーの定義であるドメインを拡張して、ドメインにはデータだけではなく操作も含むように定義した、と回答があった。

講演中に、ファウラーの本「エンタープライズ アプリケーションアーキテクチャパターン」のドメインはドメイン駆動設計では狭義の意味である、と話があったが、上記の意味であると思う。

いずれにしても、エヴァンズのドメイン駆動設計に出てくるドメインは、従来のオブジェクト指向設計よりも、かなり拡大定義しているように感じた。

【5】以上のように、僕も含めて、参加者のほとんどは、ドメイン駆動設計に出てくる「モデル」を理解できておらず、DOAや構造化設計、従来のオブジェクト指向設計の延長線上から理解しようとしていた。
だから、「ドメイン駆動設計に出てくる「モデル」とは何ですか？」という質問をずっと議論していた。

ドメイン駆動設計はメタ設計なので、話が抽象的で難しい。
にも関わらず、勉強会には40人もの参加者がいた。
ほとんどの参加者はドメイン駆動設計を理解できていないのに、何故、ドメイン駆動設計に惹かれるのか？
その理由は何だろうか？

僕の勝手な感想としては、ドメイン駆動設計には、XPやScrumに似たような匂いを感じる。
ドメイン駆動設計を読むと、「コンテキスト(文脈)」「境界づけられた文脈」「文脈の地図(コンテキスト・マップ)」「蒸留」などのプラクティスがあり、ナビゲーションマップのようなパターン言語らしき図もある。
そして、ドメイン駆動設計は、モデルの説明にコードを使っており、経験知に基づいた説明なので実践しやすい。

つまり、ドメイン駆動設計はパターン言語で語られている点が、アジャイル開発の構造に似ている。
XPやScrumはプラクティスというパターン言語として捉えられる。
プラクティス中心にアジャイル開発は説明されるので、開発者の観点では実践しやすく、とっつきやすい。

ドメイン駆動設計はパターン言語で語られているから、開発者はドメイン駆動設計に興味を持っているのではないだろうか？

僕がドメイン駆動設計に興味を持つ理由として、もう一つあげるならば、ソフトウェアプロダクトラインとの強い類似性を感じる点だ。
ドメイン駆動設計では、汎用的あるいは中心的なコアモデルから、個々のアプリケーションを作る方針の話が出てくる。
その観点は、コア資産を元に、少しだけ仕様が異なる派生した製品を作り出すプロダクトラインの話と構造的に同じだ。
あまり成功したとは言えないプロダクトラインをドメイン駆動設計の文脈で理論化したら、プロダクトラインにどのような価値を貢献できるだろうか？
その観点の思索を深めてみたいと思う。