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

@digitalsoul0124さんのBlogを読んで、自分は「ドメイン駆動設計」を完全に理解していないことに気づいた。
ラフなメモ書き。
論理的な文章でないので後で直す。

【元ネタ】
ドメイン駆動設計入門 - Digital Romanticism

モデルが息づく場所 - Digital Romanticism

戦略的デザインに関する意思決定のための６つのエッセンス - Digital Romanticism

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

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

ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

ドメイン駆動設計を考え直す: プログラマの思索

【1】ドメイン駆動設計入門 - Digital Romanticismの記事を読むと、「ドメイン駆動設計」のエッセンスをとても鮮やかにまとめているのが分かった。

業務システム開発において問題になるのは、設計モデルをSEが業務の専門家であるユーザからヒヤリングして作り、開発者に設計書に従って実装してもらうやり方はとてもロスがあること。
プロジェクトの関係者全員が共通して理解し合える業務知識(ユビキタス言語)がないのだ。
そのために、コミュニケーションロスが発生しがちで、最後のテスト工程でその事実がようやく判明する。

ドメイン駆動設計では、ユビキタス言語という概念で、プロジェクトの全員が理解し合える業務知識を共有し、モデルを育てていく。
モデルが実装モデル(浅いモデル)から分析モデル(深いモデル)へ変わる瞬間はブレイクスルーと言われ、そのタイミングでモデルの品質が一気に上がる。

ドメイン駆動設計の第7章に出てくる「ブレイクスルー」は、

ウォーターフォール型開発では、アーキテクチャは計画される
RUPでは、アーキテクチャは成長すべきものだ
アジャイル開発(XP)では、アーキテクチャは出現する

の3行目を連想させる。

そんな背景を考えると、ドメイン駆動設計は開発者のための設計技法であるように思える。
業務の専門家や設計者が設計するのではなく、開発者が中心となって、モデルを設計し、コアドメイン(コア資産)を抽出(蒸留)していく。

「ドメイン駆動設計」を読み直して改めて気づいた点は、「MVCモデルの後継者である」「ソフトウェアプロダクトラインの再構築に相当する」「パターン言語で語られる」の3つだ。

【2】ドメイン駆動設計はMVCモデルの後継者である

ソフトウェアのアーキテクチャ設計の基本は、レイヤ化モデルであり、MVCモデルであるように思える。
Smalltalkの実装技術から生まれたMVCモデルは、J2EEによるWebアプリではMVC2モデルに引き継がれた。
しかし、MVC２モデルでは、Controllerにロジックを書く労力が多すぎて、本来のMVCモデルではない。

ドメイン駆動設計入門 - Digital Romanticismでも書かれているように、「リクエストに対する処理を手続き型に記述するスタイルが、いわゆる「トランザクションスクリプト」」のスタイルが多い。
実際、「「モデルは業務処理を書く場所」と覚えて、アプリケーションの実装に入った方がほとんどだと思うのですが、そこで実際に書いているコードは、if/forを駆使してList/Mapを操作するというスタイルが多いのではないでしょうか。」

ドメイン駆動設計では、4つのレイヤー型アーキテクチャが提唱されている。
・ユーザインタフェース（プレゼンテーション）レイヤ
・アプリケーションレイヤ
・ドメインレイヤ
・インフラストラクチャレイヤ

@hatsanhatさんが言われるように、渡辺式三要素分析法(DOA)と対比させると、
・ユーザインターフェイス層：業務構成
・ドメイン層：機能構成
・インフラストラクチャ層：データ構成(ER図)
に相当する。
つまり、業務システムの設計モデルにおいても、MVCモデルで整理することができる。

この考え方では、システムを使うユーザ企業の担当者は、機能構成図(あるいはユースケース図)で示した機能からシステムを理解している。
また、業務システムのロジックは、業務フロー図などで表現されており、ドメイン駆動設計ならドメイン層、渡辺式三要素分析法なら業務構成で表現される。
この部分が設計の腕の見せ所。
インフラ層はデータ層であり、それはクラス図ないしER図で表現される。

MVCモデルをきちんと適用できれば、Controllerの肥大化やトランザクションスクリプトで設計・実装する必要もなく、もっと綺麗なモデルになるはず。

【3】ドメイン駆動設計はパターン言語で語られる、

「ドメイン駆動設計」を改めて読み直すと、ユビキタス言語、境界づけられた文脈、文脈の地図、の説明文の中に「それゆえ」という単語があるのに気付く。
「それゆえ」の内容は、Coplienのパターンにおける解決策に相当しているのだ。

また、ナビゲーションマップがパターン言語になっているのが分かる。
ユビキタス言語、境界づけられた文脈、文脈の地図などの概念が矢印で結ばれているのは、それぞれの概念はバラバラではなく、一つの体系として見るとパターン言語になっていることを意味しているのだと思う。

実際、ナビゲーションマップは組織パターンに出てくるパターン言語の構造にとてもよく似ている。

そんな観点で読み直すと、「ドメイン駆動設計」は読んでいて、とても気持ちいい。
抽象的な設計技法の本ではなく、現場で試行錯誤しながら生み出された設計技法であると感じられて、共感できるからだ。

【4】ドメイン駆動設計はソフトウェアプロダクトラインの再構築に相当する

ドメイン駆動設計は単なるオブジェクト指向設計ではなく、ソフトウェアプロダクトラインの再構築ないし実装プロセスとして捉えるべきではないか、と思っている。

ソフトウェアプロダクトラインでは、多品種少量生産の開発プロセスとして提唱された。
例えば、AppleのiPod/iPhone/iPadのように、多数の製品系列は共通基盤の上に仕様が微妙に異なるアプリケーションを実装していくのに使われる。
ドメイン駆動設計で出てくる概念を下記のように、ソフトウェアプロダクトラインに当てはめてみると、とても理解が進む。

ソフトウェアプロダクトラインの概念としては、共通基盤となるモデルであるコア資産が、ドメイン駆動設計ではコアドメインに相当する。
そして、コア資産の抽出が、ドメイン駆動設計では蒸留というプロセスに似ている。
プロジェクト内部の全員が共有しているモデルはユビキタス言語で語られるが、これはプロダクトの業務知識に相当するだろう。
境界づけられた文脈は、モデルのコンテキスト(文脈)が適用できる有効範囲であり、その範囲を超えると別の意味になる場合がある。

ドメイン駆動設計の第14章「モデルの整合性を維持する」P.347に出てくる「境界づけられたコンテキスト内での分派を認識する」とは、ホノニムやシノニムに相当するだろうと思う。
つまり、一つの概念が、人によっては別の意味に捉えられてしまうことを意味しているのだろう。

それら文脈間の関係は文脈の地図で整理され、大局的に理解できるようにする。
それは、システムの業務知識を一つの地図として見渡せるようにすることに対応している。

システムが大規模になるにつれて理解しにくくなるが、システムのメタファを用いて、モデルの要素を表す具体的な比喩で理解して深める。
その理解を更に深めて蒸留して、ユビキタス言語に取り入れる。
本来はXPのプラクティスであるメタファから発生しているらしいが、モデルを理解するプロセス(メタファ→ユビキタス言語)に相当するだろうと思う。

このように、ドメイン駆動設計に出てくる概念はとても抽象的だが、ソフトウェアプロダクトラインにマッピングさせると、まさにソフトウェアプロダクトラインを実装しているかのように思える。
ソフトウェアプロダクトラインの弱点は、コア資産の抽出が難しいことと、技術の変化についていけずにコア資産が陳腐化してしまうことなどがあげられる。
でも、ドメイン駆動設計を使って、反復的にモデルを蒸留させていけば、うまくいく可能性があると思う。

但し、ドメイン駆動設計を適用できる有力な事例がソフトウェアプロダクトラインであるとすれば、ドメイン駆動設計はかなり敷居の高い手法であるかもしれない。
なぜなら、ソフトウェアプロダクトラインは10年以上前から研究されて実践されているのに、実際は、再利用できるコア資産の抽出が難しかったり、開発プロセスにコストがかかりすぎるなどの弱点を言われ続けてきたからだ。
ドメイン駆動設計がソフトウェアプロダクトラインの弱点をカバーできるならば、おそらくうまくいくのではないか？

そのアイデアも考えてみる。

【追記】12/13にドメイン駆動設計の勉強会があります。興味のある方はご参加ください。

第28回　関西IT勉強宴会 : ATND