ドメイン駆動設計の実践例

経営管理基盤 fusion_place IT勉強宴会

Nov.6, 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/

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

2. ドメイン駆動設計の実践例 - fusion_place -

3. fusion_place デモンストレーション

4. DSPドメインモデラーへの道

目次

ドメイン駆動設計とは何か

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

(※)エリック・エヴァンス, 2011年,「エリック・エヴァンスのドメイン駆動設計」翔泳社、以下「DDD本」 表表紙と裏表紙のパターン関連図および日本語版への序文（後者では「コアドメイン」も原則とされている）

モデル駆動

モデルを、問題領域（分析対象）ではなく、解決領域（設計対象）に属するものと捉えなおす。

ドメイン駆動設計の 原則(※） 意味（私見）

ドメイン駆動設計(※)とは、オブジェクト指向ベースの知識体系を受け入れつつも、エンジニアの関心を、プログラムのテクニカルな構造に留まらず情報処理モデルそれ自体の構築に向けようとする試みである（私見）。

上記原則のもとで、実践方法をオブジェクト指向ベースで示している。 例. エンティティ、サービス、リポジトリ、値オブジェクト、・・・

ユビキタス言語

ＯＯ方法論で一般的な分析モデルと設計モデルの区別をなくし、モデルとプログラム構造の一致を図る。

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

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

要件がある

持分計算表

オブジェクト

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

しくみ

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

問題領域

解決領域

問題領域 解決領域

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

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

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

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

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

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

解決領域

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

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

問題領域

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

B. エンジニア 解決領域

（設計モデル）

問題領域（分析モデル）

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

DDDの２つの「ひねり」

DDDの 「ひねり」

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

事業活動のモデルと

ドメインモデルの

切り離し

ドメインモデルと

プログラム構造の統合

「ユビキタス言語」

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

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

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

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

DDDとDOAの同型性

DDDの 「ひねり」

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

事業活動のモデルと

ドメインモデルの

切り離し

ドメインモデルと

プログラム構造の統合

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

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

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

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

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

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

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

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

ドメイン駆動設計の実践例

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 リンク領域定義

アクセス許可タイプ

ワークフロー

元帳版

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

ワークスペース

締め管理

解決領域による問題の変容

予算をバージョン管理したい！

漠然としたニーズに対する解決策を、解決領域の語彙で表現しようとしたときに、問題の分析を強制される。

問題領域 解決領域 (fusion_place)

解決領域による問題の変容

予算をバージョン管理したい！

シナリオ

元帳版

提出データ履歴

ワークスペース

期中予算改訂の履歴

集計作業途上の

スナップショット確保

提出し直した場合の

各回のデータの記録

各部署での未確定の

作業データの分析

漠然としたニーズに対する解決策を、解決領域の語彙で表現しようとすることを通じて、問題の分析が深まる。

問題領域 解決領域 (fusion_place)

fusion_place デモンストレーション

DSPドメインモデラーへの道

ドメインモデラーの重要性(1/2)

ＤＳＰを活用するドメインモデラー=コンサルタントには、ドメインにおけるニーズとＤＳＰのソリューションを創造的に結びつけるスキルが要求される。

本社の費用を事業部に配賦（割り振り）したい！

1. 配賦とは何かといった一般的ドメイン知識

2. 配賦に関する fusion_place ドメインモデルのパターンとパターン外の工夫

① 配賦元／先別部門別の配賦額を保持するための元帳

② 配賦前／後のデータを保持するディメンション

③ 配賦計算フォームの設定の定石

3. そもそもこの顧客企業で本社費を配賦するのが適切かと考える分別

4. 上記のような考えにつき、攻撃的ではなく相手と話し合うことができるバランス感覚

ユーザのニーズ（例）

ドメインモデラー／コンサルタントに要求される素養

ドメインモデラーの重要性(2/2)

ＤＳＰによって技術的詳細が隠蔽されるため、ドメインモデラーのスキルセットは、ユーザの関心事に近い方向にシフトすることができる。

JavaScript ベースのUIフレームワーク 認証／セッション管理手法 DBパーシスタンスライブラリ ...

ＳＥへの要求スキル

基本的な業務知識 業務分析／データモデリング プロジェクト推進手法...

管理会計のための費用分類のあり方 予算実績差異分析の手法 連結ベースでの予算編成手法 ...

ドメインモデラーへの

要求スキル

fusion_place の場合のスキル例

管理職レベル

fusion_place メタモデルに関する知識 fusion_placeでの定石（デザインパターン）...

実務レベル

ユーザの関心事

基本

上級

今までと同じことを、早く・安くやるのが目的ではない。 今までと違う付加価値を提供するための DSP

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

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

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

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

ー 終わりに ー

フィードバック重要

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

終わり