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

新たな関係

DDD.rb #5 Dec.19, 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. ＤＤＤの拡張可能性

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

目次

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

・・・根本的には、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では...

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

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

ＤＤＤの実践例 ある連結会計パッケージの開発時、「資本連結」と呼ばれる複雑な会計処理にオブジェクト指向を適用した。

連結会計報告 の中に資本連結という

要件がある

持分計算表

オブジェクト

「持分計算表」 という計算の

しくみ

事象活動の領域 情報処理の領域 コンピュータ処理の領域

問題領域

解決領域

問題領域 解決領域

• ドメインエキスパートの間では、持分計算表は古くから知られている。

• ただし標準化されたものではなく、このソフトウェア設計時にも独自の工夫が施された。

• モデルは、クラス／インターフェース／メソッド等オブジェクト指向を踏まえて作成された。.

A. 業務担当者・会計士 （＝ドメインエキスパート）

B.エンジニア （＝ドメインモデラー）

問題領域 【この時の役割分担】

解決領域

※ 色付けは各役割が主に担当する分野。

（一元化されたドメインモデル）

問題領域

A. ドメインエキスパート ＋アナリスト（？）

B. エンジニア 解決領域

（設計モデル）

問題領域（分析モデル）

【ありがちな役割分担】 事業活動領域と情報処理領域の間の問題／解決対立構造が見落とされてしまう。

DDDの適用領域

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

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

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

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

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

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

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

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

DDDとオブジェクト指向

ユビキタス

言語

モデル駆動

設計

コア

ドメイン

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

サービス …

原則レイヤのパターン群

実践レイヤのパターン群

オブジェクト指向には、

依存していない。

オブジェクト指向に

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

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

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

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

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

終わり

≪おまけ≫

DDD + GP = DSP-driven Development.

- fusion_placeを題材に -

経営管理ドメインの独自性

計画 計画/実績

報告

指図 実績記録

実行

経営管理 (Management)

取引処理 (Transaction Processing)

作業実施 (Operation)

活動レベル

自動倉庫 工作機制御 EOS POS 電子銀行...

販売管理 請求・支払 生産管理 受注・発注...

ERP 超高速 開発

専用 システム

群

予算 経営報告 財務報告 販売計画 ...

BI 表計算

企業活動 ITによる対応 従来

MI

今後

ERP

専用 システム

群

取引処理領域と経営管理領域では 情報処理ニーズが異なる

経営管理ドメインには取引処理ドメインとは異なるタイプの情報処理ニーズが存在します。このニーズに的確に対応するソフトが無いため、現状は複数ツールの合わせ技で対応されている。fusion_place はこの現状を打破する意図で作られたドメイン特化基盤（ＤＳＰ）である。

DDD on fusion_place

ドメイン特化基盤（ＤＳＰ）の採用により、ドメインについての知識を持つ一方で基盤寄りの開発スキルを持たないエンジニアがＤＤＤを実践できるようになる。

管理会計制度 の中に事業別業績管理

という要件がある

「事業別Ｐ/Ｌ」 の保持・計算のしくみ

事象活動の領域 情報処理の領域

ドメインモデル

業務担当者 （＝ドメインエキスパート） 問題領域 解決領域

モデリングパラダイム （ＤＳＰが提供するメタモデル）

問題領域 解決領域 ドメインモデラー （＝コンサルタント）

元帳（キューブ）

ディメンション

事業別P/L元帳

配賦計算元帳

事業ディメンション

配賦種別ディメンション

フォーム

fusion_place

基盤(DSP)

配賦計算フォーム

DSPがメタモデルを提供する ⇓ ・プログラミング自由度は減る。 ・ドメインにあった高級概念を使える。 ・より高度なシステムを、より短期間で 構築できる。

拘束する

fusion_placeのメタモデル

ＤＳＰは、ドメインにおけるニーズの共通性への洞察を踏まえ、適度に抽象化されたドメインモデルを提供する。これがアプリケーションにとってはメタモデルとなる。

（例）fusion_place のメタモデル（一部、要約）

ディメンション 元帳 … 多次元データ管理

汎用 式言語 テキスト式 (DSL)

データアクセス制御 業務責任単位

入出力手段 フォーム定義（DSL） Excel-Link リンク領域定義

アクセス許可タイプ

ワークフロー

元帳版

業務プロセス定義 業務プロセス 部署別

ワークスペース

締め管理

DDD in fusion_place

ドメイン特化基盤（ＤＳＰ）の設計/開発は、通常のＤＤＤそのもの。ただしそのドメインモデルはアプリケーションレイヤのメタモデルである。

マネジメントインテリジェンスシステム（*)

の構築

多次元データの

加工・処理・提示

のしくみ

事象活動の領域 情報処理の領域

ドメインモデル

B. DSPモデラー

問題領域 解決領域

モデリングパラダイム （OOPメタモデル）

問題領域 解決領域

Ａ. ドメインモデラー （＝コンサルタント）

エンティティ

値クラス

元帳（キューブ）

ディメンション

フォーム

フォーム定義(DSL)

Java etc..

基盤(言語・インフラ)

テキスト式(DSL)

（*) 計画／分析／報告を含む経営管理のための情報処理システムの包括的呼称。フュージョンズが提唱。

拘束する

DDD + GP = DSP-driven Dev.

Generative Programming は、ソフトウェア開発を、ドメインエンジニアリング（ソフトウェアファミリ開発）とアプリケーションエンジニアリング（ソフトウェアインスタンス開発）に分かつ。ＤＤＤは前者だけでなく後者にも適用することができる。

ＤＳＰレイヤ

アプリケーションレイヤ

ドメインモデル

ユビキタス言語

ＤＳＬ

モデリングパラダイム

ドメインモデル

ユビキタス言語

アプリケーションエンジニアリング

ドメイン

エンジニアリング

下位層のドメインモデルが

上位層にとってのモデリングの枠組みを提供する。

仕事のプロ、仕組みづくりのプロ、道具作りのプロの間で、フィードバックループがうまくつながるような業界になることを願っています。

業務のプロ (自社業務への精通+業務へのオーナーシップ)

業務設計（仕組みづくり）のプロ （ITの素養＋業務設計力＋ツールへの精通）

道具作りのプロ （ITの深い知識＋要件の概念化・抽象化スキル）

フィードバック重要

この図は、2010年8月18日の第１回関西ＩＴ勉強宴会で、fusion_place をご紹介した折にお示しした ものです。

本当に終わり