ドメイン駆動設計 ユーザー、モデル、エンジニアの

新たな関係

ＰＨＰメンターズセミナー in ＰＨＰカンファレンス

Oct.3, 2015

杉本 啓 twitter: @sugimoto_kei

http://www.fusions.co.jp

自己紹介 • 会計事務所系コンサルティング会社（アクセンチュア／アンダーセン）出身。

• 生産管理/会計系基幹システム構築 (スクラッチ開発, SAP R/3等)

～ 会計・経営管理領域の制度設計・業務改革

～ パッケージソフト（連結会計）開発など。

• 2003年独立、経営管理基盤ソフトウェア「fusion_place」の開発販売・導入支援。

http://www.fusions.co.jp

• 現役 Java プログラマ。OOPラブ × XPラブ × DOAラブ。

• 全然アップデートしていないブログあり。

http://hot-heart-cool-mind.seesaa.net/

• 「ＩＴ勉強宴会」で時々おしゃべり ＆ いつも Drink!

http://www.benkyoenkai.org/

＜日経BP谷島さんによる紹介記事＞

http://business.nikkeibp.co.jp/article/campanella/20141016/272649/

1. ドメイン駆動設計とは

2. ドメイン駆動設計の３つの原則

3. ３つの原則からみたＤＤＤ本の構成

4. ドメインとドメインモデル

5. ドメインモデルとは何か

6. ドメインに浸潤するドメインモデル

7. ＤＤＤの２つの「ひねり」

8. ＤＤＤとＤＯＡの同型性

9. ＤＤＤとオブジェクト指向

10. ＤＤＤの適用領域

11. ＤＤＤの拡張可能性

12. ドメイン・エンジニアリング ～ＤＤＤの射程～

目次

「ドメイン駆動設計」とは

・・・根本的には、DDDを駆動している原則は次の３つだけです。

コアドメインに集中すること。

ドメインの実践者とソフトウェアの実践者による創造的な共同

作業を通じて、モデルを探求すること。

明示的な境界づけられたコンテキストの内部で、

ユビキタス言語を語ること。

DDD本(※)「日本語版への序文」by エリック・エヴァンス

(※)エリック・エヴァンス, 2011年,「エリック・エヴァンスのドメイン駆動設計」翔泳社、以下同

ドメイン駆動設計の３つの原則

ユビキタス

言語

モデル駆動

設計

（※）DDD本 表表紙と裏表紙のパターン関連図

適用範囲の選択

に関する原則

適用範囲での設計のあり方

に関する原則

コアドメイン

本日は、主に下側の２つの原則について考察します。

３つの原則のうち、２つ（ユビキタス言語とモデル駆動設計）は、原著発刊時に書かれたパターン関連図（※）で中核に位置付けられている。 「コアドメイン」は、中核には位置付けられていなかったが、本文を読むと、当初から重視されていたことがわかる。

３つの原則からみたDDD本の構成

第１部 ドメインモデルを機能させる ⇒ユビキタス言語とモデル駆動の紹介

第２部 モデル駆動設計の構成要素 ⇒モデルと実装の結び付け方

第３部 より深い洞察に向かうリファクタリング ⇒モデルを洗練させる方法

第４部 戦略的設計 ⇒コアドメインへの集中の強調と、集中のための具体的手法

DDD本の構成

第２部の位置づけが難しい。

第２部を中心に読むと：

オブジェクト指向の適用パターン本に見える。

その割には、内容に新味がない（2003年の原著発刊時点でも）。

とはいえ、多くの現場で出来ていないのは確かなので、啓蒙的効果はある。

でも、それでは、ユビキタス言語とモデル駆動を強調する意味がわからない...

ドメイン・ドメインモデル・モデル駆動・ユビキタス言語の意味を、

あらためて、考えてみましょう。

《質問》

ドメインモデルはドメインのモデルなのでしょうか？

ドメインとドメインモデル 例： ソースコード管理システム

ドメイン

（問題領域）

ソースコード

管理

Subversion

Git

「コミット」の意味

「コミット」という言葉は、ドメインモデルの一部のはずですが...

「コミット」の定義はドメインにではなく、ツールに依存する。

ソースコード管理システムが世に現れて初めて「コミット」という言葉

が「リポジトリへの変更登録」という意味で使われ始めた。

セントラルリポジトリへの

変更登録 （登録時に競合があり得る）

ローカルリポジトリへの

変更登録 （登録ににの競合はあり得ないが、別途、

push などでリポジトリ間同期必要）

ツール

（解決領域）

ドメインモデルとは何か(1/2) ドメインモデルは：

こちらではなく... ...こちらではないでしょうか。

問題領域（ドメイン）のモデル。 解決領域（ツール）のモデル。 但し、ソフトの内部構造ではなく、

ユーザも理解すべき、情報処理のモデル。

あらかじめ存在する、分析対象。 ソリューションの開発に際して、意図的に設計する対象。

ドメイン・エキスパートが

知っている。

ドメイン・エキスパートの知見を踏まえながら、我々エンジニアも考える。

ドメインモデルは、ソリューションのモデル。

そしてエンジニアリングの結果、生まれるものである。

ドメインモデルとは何か(2/2)

ＤＤＤ本では、船舶／コンテナが登場するモデルと、

船荷証券等が登場するモデルの差異を、深さの違いと捉えているが、

モデル化の対象が異なると考えた方が適切。

事業における、

具体的な活動。

事業活動を制御する管理／統制活動。

モデル化対象

船舶 コンテナ

本船・次航 (vessel voyage) 船荷証券(B/L)

DDD本での例 （p. 191-192）

【参考】 DOAでの呼称例（※）

事業過程

管理過程

「浅いモデル」

情報とその動き

ヒト・モノ・カネ

とその動き

「深いモデル」

(※) 佐藤正美, 2005年,「データベース設計論-Ｔ字形ＥＲ」, ソフト・リサーチ・センター、p.34-35

ドメインモデルは事業活動自体のモデルではなく、事業活動を支える情報処理のモデル。両者は必ずしも一致しない。

《問題領域》

《解決領域》

事業活動の

モデル

ドメイン

モデル

モデル

相互依存

ドメインに浸潤するドメインモデル

情報処理（解決領域）のモデルであるドメインモデルが、ドメイン（問題領域）のモデルであるかのように見られがちなのは、多くのドメインが、ドメインモデルにより浸潤されているから。

ドメイン 浸潤しているドメインモデル

会計 複式簿記 本来的には帳簿記録を組織化するためのひとつの手法・パターンに過ぎない。

貿易 船荷証券 貿易慣行の中で確立され、法制度化された、取引に関する事務処理パターン。

鉄道運行 ダイヤ 運行スケジュールを線引きするために工夫された手書き図（ダイヤグラム）。これも事業活動をサポートするための情報処理パターン。

モデリング ＵＭＬ モデリング自体は図的表記がなくとも可。UMLでなくとも可。

ドメインモデルは情報処理のモデルだから、

コンピュータの登場以前に成立／普及している場合もある。

これらは容易に、ドメインそのものと混同されてしまう。

二元的モデルと三元的モデル

OOA※で一般的な モデル観

（DDD本 p.46）

分析モデル 設計モデル

問題領域／分析対象（＝与件） 解決領域／設計対象

ドメインモデル

の導入

事業活動の

モデル

プログラム構造

のモデル ドメイン

モデル

DDDの モデル観 （私見）

事業活動の

モデル

プログラム構造

のモデル ドメイン

モデル

ドメインモデル＝ユビキタス言語

(単一のモデル)

DDDのモデル観は一周回って二元的モデルに戻っているが、 境界線の位置が一般的なOOAとは異なっている。（私見）

※ オブジェクト指向分析

DDDの２つの「ひねり」

DDDの 「ひねり」

２つの「ひねり」によって、DDDは、エンジニアリングの対象領域を広げつつ、 エンジニアリング活動内部の分裂を防止しようとしている（私見）。

事業活動のモデルと

ドメインモデルの切り離し

ドメインモデルと

プログラム構造の統合

「ユビキタス言語」

「モデル駆動アプローチ」

ドメインモデルを、ユーザ所有物から共同所有物に転化する。

ドメインモデルとソースコードの乖離によるドメインモデルの形骸化を防ぐ。

ＤＤＤでは、以下の２つの「ひねり」を通じて「境界線の引き替え」を行っている。

DDDとDOAの同型性

DDDの 「ひねり」

DDDとDOA、根本的な発想は共通で、 実装に適用するパラダイム※とアプローチが異なる。

事業活動のモデルと

ドメインモデルの切り離し

ドメインモデルと

プログラム構造の統合

当然の認識 佐藤正美：事業過程／管理過程

渡辺幸三：データモデルは帳簿組織

DSLによるドメインモデル記述に基づく

自動生成／動的制御で対応

（モダンな）DOAでは...

ＤＯＡは、ソフトウェア開発というより業務システム開発の現場で育ってきたため、２つの「ひねり」は、むしろ当然の前提（当然過ぎて議論に上りにくい）。

※ 分析や設計に適用する枠組み・文法

DDDとオブジェクト指向

ユビキタス

言語

モデル駆動

設計

コア

ドメイン

エンティティ 値オブジェクト

サービス …

原則レイヤのパターン群

実践レイヤのパターン群

オブジェクト指向には、

依存していない。

オブジェクト指向に

依存している部分が相当ある。

特に、ユビキタス言語の文法を 提示している第２章のパターン群。

ＤＤＤ本は、実践レイヤのパラダイムとしてオブジェクト指向を採用しているが、 ＤＤＤの原則自体はオブジェクト指向から独立している。

ＤＤＤは全体としてパターン言語を形成している。この言語は、「原則」レイヤと「実践」レイヤに分かつことが出来る。

DDDの適用領域

ＤＤＤ本は、エヴァンス氏の経験から生まれた。その経験は以下のようなプロジェクトを通じて培われたものである（ＤＤＤ本「エピローグ」）。

1. 商用のPCB（プリント基板）設計用ソフトウェア

2. 複数の金融機関が利用するローンソフトウェア

3. 大手国際輸送会社の輸送業務システム

4. 商用の在庫管理ソフトウェア

いずれも、継続的開発が当然で、汎用性や柔軟性を重視した設計が 見合う（コスト合理性がある）ケース。

３カ月で稼働／納品して後は最小限のメンテしかされないソフトではない。

４つのうち３つが商用パッケージソフトウェア。 残りひとつ(3)は、開発した企業の戦略的優位性の中核にあるようなソフト。

DDDの拡張可能性

ＤＤＤの原則はそのままに、プラクティス（実践手法）を入れ替えることで、ＤＤＤ自体を拡張できると思われる。

ユビキタス

言語 モデル駆動

コア

ドメイン

オブジェクト指向 リレーショナルモデル 多次元データモデル

ＤＤＤ本の

ＤＤＤ

（モダンな）ＤＯＡ

（ ≒超高速開発※2）

DDD on fusion_place

…

…

汎用言語 ＤＳＬ(※1) ＤＳＬ

(※1) ＤＳＬ＝ドメイン特化言語 (※2) 「超高速開発」は、開発が速くなることに価値を見出した呼称ですが、DDDの文脈ではむしろ、設計／開発の

フォーカスをドメインモデルの（再）設計に移すことに価値を求めることが可能と思われます。

中核パラダイム

記述言語水準

開発アプローチ

ドメイン・エンジニアリング

～ ＤＤＤの射程 ～

ドメインモデルを設計対象とするなら、我々は、ユーザとともに業務や取引の方式を設計することも出来る。システム設計はもっとクリエイティブになる。

ドメイン ドメインモデルパターン

販売／生産管理 ・ＭＲＰを代替／補完する「在庫推移監視方式」。 (※)

会計／経営管理

・複式簿記の拡張形としての「増減複式簿記」。

・複雑化する管理会計／財務報告に適した「二層帳簿モデル」。

・変化する経営環境に追随する「環境適応型予算管理モデル」。

ＤＤＤの「原則」は、 ＤＤＤ本が示している「実践」より、はるかに広く遠い射程を

持っているのではないでしょうか。

http://hot-heart-cool-mind.seesaa.net/article/393131426.html

http://hot-heart-cool-mind.seesaa.net/article/393131365.html

http://www.fusions.co.jp/mail-magazine/mm-003/

(※) 渡辺幸三, 2002年,「生産管理・原価管理のためのデータモデリング」, 日本実業出版社、p.188

終わり