Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ドメイン駆動設計 at DDD.rb #5
Similar to ドメイン駆動設計 at DDD.rb #5 (20)
Recently uploaded
Recently uploaded (9)
ドメイン駆動設計 at DDD.rb #5
- 1. ドメイン駆動設計 ユーザー、モデル、エンジニアの 新たな関係 DDD.rb #5 Dec.19, 2015 杉本 啓 twitter: @sugimoto_kei http://www.fusions.co.jp
- 2. 自己紹介 • 会計事務所系コンサルティング会社（アクセンチュア／アンダーセン）出身。 • 生産管理/会計系基幹システム構築 (スクラッチ開発, 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/
- 3. 1. ドメイン駆動設計とは 2. ドメイン駆動設計の３つの原則 3. ３つの原則からみたＤＤＤ本の構成 4. ドメインとドメインモデル 5. ドメインモデルとは何か 6. ドメインに浸潤するドメインモデル 7. ＤＤＤの２つの「ひねり」 8. ＤＤＤとＤＯＡの同型性 9. ＤＤＤの実践例 10. ＤＤＤの適用領域 11. ＤＤＤとオブジェクト指向 12. ＤＤＤの拡張可能性 13. ドメイン・エンジニアリング ～ＤＤＤの射程～ 目次
- 6. ３つの原則からみたDDD本の構成 第１部 ドメインモデルを機能させる ⇒ユビキタス言語とモデル駆動の紹介 第２部 モデル駆動設計の構成要素 ⇒モデルと実装の結び付け方 第３部 より深い洞察に向かうリファクタリング ⇒モデルを洗練させる方法 第４部 戦略的設計 ⇒コアドメインへの集中の強調と、集中のための具体的手法 DDD本の構成 第２部の位置づけが難しい。 第２部を中心に読むと： オブジェクト指向の適用パターン本に見える。 その割には、内容に新味がない（2003年の原著発刊時点でも）。 とはいえ、多くの現場で出来ていないのは確かなので、啓蒙的効果はある。 でも、それでは、ユビキタス言語とモデル駆動を強調する意味がわからない...
- 9. ドメインとドメインモデル 例： ソースコード管理システム ドメイン （問題領域） ソース コード 管理 Subversion Git 「コミット」の意味 「コミット」という言葉は、ドメインモデルの一部のはずですが... 「コミット」の定義はドメインにではなく、ツールに依存する。 ソースコード管理システムが世に現れて初めて「コミット」という言葉 が「リポジトリへの変更登録」という意味で使われ始めた。 セントラルリポジトリへの 変更登録 （登録時に競合があり得る） ローカルリポジトリへの 変更登録 （登録ににの競合はあり得ないが、別途、 push などでリポジトリ間同期必要） ツール （解決領域）
- 10. ドメインモデルとは何か(1/2) ドメインモデルは： こちらではなく... ...こちらではないでしょうか。 問題領域（ドメイン）のモデル。 解決領域（ツール）のモデル。 但し、ソフトの内部構造ではなく、 ユーザも理解すべき、情報処理のモデル。 あらかじめ存在する、分析対象。 ソリューションの開発に際して、 意図的に設計する対象。 ドメイン・エキスパートが 知っている。 ドメイン・エキスパートの知見を踏 まえながら、我々エンジニアも考え る。 ドメインモデルは、ソリューションのモデル。 そしてエンジニアリングの結果、生まれるものである。
- 11. ドメインモデルとは何か(2/2) ＤＤＤ本では、船舶／コンテナが登場するモデルと、 船荷証券等が登場するモデルの差異を、深さの違いと捉えているが、 モデル化の対象が異なると考えた方が適切。 事業における、 具体的な活動。 事業活動を制御する 管理／統制活動。 モデル化対象 船舶 コンテナ 本船・次航 (vessel voyage) 船荷証券(B/L) DDD本での例 （p. 191-192） 【参考】 DOAでの呼称例（※） 事業過程 管理過程 「浅いモデル」 情報とその動き ヒト・モノ・カネ とその動き 「深いモデル」 (※) 佐藤正美, 2005年,「データベース設計論-Ｔ字形ＥＲ」, ソフト・リサーチ・センター、p.34-35 ドメインモデルは事業活動自体のモデルではなく、事業活動を支える情報処理 のモデル。両者は必ずしも一致しない。 《 問 題 領 域 》 《 解 決 領 域 》 事業活動の モデル ドメイン モデル モデル 相互依存
- 12. ドメインに浸潤するドメインモデル 情報処理（解決領域）のモデルであるドメインモデルが、ドメイン（問題領 域）のモデルであるかのように見られがちなのは、多くのドメインが、ドメイ ンモデルにより浸潤されているから。 ドメイン 浸潤しているドメインモデル 会計 複式簿記 本来的には帳簿記録を組織化するためのひとつ の手法・パターンに過ぎない。 貿易 船荷証券 貿易慣行の中で確立され、法制度化された、取 引に関する事務処理パターン。 鉄道運行 ダイヤ 運行スケジュールを線引きするために工夫され た手書き図（ダイヤグラム）。これも事業活動 をサポートするための情報処理パターン。 モデリング ＵＭＬ モデリング自体は図的表記がなくとも可。UML でなくとも可。 ドメインモデルは情報処理のモデルだから、 コンピュータの登場以前に成立／普及している場合もある。 これらは容易に、ドメインそのものと混同されてしまう。
- 13. 二元的モデルと三元的モデル OOA※で一般的な モデル観 （DDD本 p.46） 分析モデル 設計モデル 問題領域／分析対象（＝与件） 解決領域／設計対象 ドメインモデル の導入 事業活動の モデル プログラム構造 のモデル ドメイン モデル DDDの モデル観 （私見） 事業活動の モデル プログラム構造 のモデル ドメイン モデル ドメインモデル＝ユビキタス言語 (単一のモデル) DDDのモデル観は一周回って二元的モデルに戻っているが、 境界線の位置が一般的なOOAとは異なっている。（私見） ※ オブジェクト指向分析
- 16. ＤＤＤの実践例 ある連結会計パッケージの開発時、「資本連結」と呼ばれる複雑な会計処理に オブジェクト指向を適用した。 連結会計報告 の中に資本連結という 要件がある 持分計算表 オブジェクト 「持分計算表」 という計算の しくみ 事象活動の領域 情報処理の領域 コンピュータ処理の領域 問題領域 解決領域 問題領域 解決領域 • ドメインエキスパートの間では、持分計算表は古くから知られている。 • ただし標準化されたものではなく、このソフトウェア設計時にも独自の工夫が施された。 • モデルは、クラス／インターフェース／メソッド等オブジェクト指向を踏まえて作成された。. A. 業務担当者・会計士 （＝ドメインエキスパート） B.エンジニア （＝ドメインモデラー） 問題領域 【この時の役割分担】 解決領域 ※ 色付けは各役割が主に担当する分野。 （一元化されたドメインモデル） 問題領域 A. ドメインエキスパート ＋アナリスト（？） B. エンジニア 解決領域 （設計モデル） 問題領域（分析モデル） 【ありがちな役割分担】 事業活動領域と情報処理領 域の間の問題／解決対立構 造が見落とされてしまう。
- 17. DDDの適用領域 ＤＤＤ本は、エヴァンス氏の経験から生まれた。その経験は以下のようなプロ ジェクトを通じて培われたものである（ＤＤＤ本「エピローグ」）。 1. 商用のPCB（プリント基板）設計用ソフトウェア 2. 複数の金融機関が利用するローンソフトウェア 3. 大手国際輸送会社の輸送業務システム 4. 商用の在庫管理ソフトウェア いずれも、継続的開発が当然で、汎用性や柔軟性を重視した設計が 見合う（コスト合理性がある）ケース。 ３カ月で稼働／納品して後は最小限のメンテしかされないソフトではない。 ４つのうち３つが商用パッケージソフトウェア。 残りひとつ(3)は、開発した企業の戦略的優位性の中核にあるようなソフト。
- 19. DDDの拡張可能性 ＤＤＤの原則はそのままに、プラクティス（実践手法）を入れ替えることで、 ＤＤＤ自体を拡張できると思われる。 ユビキタス 言語 モデル駆動 コア ドメイン オブジェクト指向 リレーショナルモデル 多次元データモデル ＤＤＤ本の ＤＤＤ （モダンな）ＤＯＡ （ ≒超高速開発※2） DDD on fusion_place … … 汎用言語 ＤＳＬ(※1) ＤＳＬ (※1) ＤＳＬ＝ドメイン特化言語 (※2) 「超高速開発」は、開発が速くなることに価値を見出した呼称ですが、DDDの文脈ではむしろ、設計／開発の フォーカスをドメインモデルの（再）設計に移すことに価値を求めることが可能と思われます。 中核パラダイム 記述言語水準 開発アプローチ
- 20. ドメイン・エンジニアリング ～ ＤＤＤの射程 ～ ドメインモデルを設計対象とするなら、我々は、ユーザとともに業務や取引の 方式を設計することも出来る。システム設計はもっとクリエイティブになる。 ドメイン ドメインモデルパターン 販売／生産管理 ・ＭＲＰを代替／補完する「在庫推移監視方式」。 (※) 会計／経営管理 ・複式簿記の拡張形としての「増減複式簿記」。 ・複雑化する管理会計／財務報告に適した「二層帳簿モデル」。 ・変化する経営環境に追随する「環境適応型予算管理モデル」。 ＤＤＤの「原則」は、 ＤＤＤ本が示している「実践」より、はるかに広く遠い射程を 持っているのではないでしょうか。 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
- 21. 終わり
- 22. ≪おまけ≫ DDD + GP = DSP-driven Development. - fusion_placeを題材に -
- 24. DDD on fusion_place ドメイン特化基盤（ＤＳＰ）の採用により、ドメインについての知識を持つ一 方で基盤寄りの開発スキルを持たないエンジニアがＤＤＤを実践できるように なる。 管理会計制度 の中に事業別業績管理 という要件がある 「事業別Ｐ/Ｌ」 の保持・計算のしくみ 事象活動の領域 情報処理の領域 ドメインモデル 業務担当者 （＝ドメインエキスパート） 問題領域 解決領域 モデリングパラダイム （ＤＳＰが提供するメタモデル） 問題領域 解決領域ドメインモデラー （＝コンサルタント） 元帳（キューブ） ディメンション 事業別P/L元帳 配賦計算元帳 事業ディメンション 配賦種別ディメンション フォーム fusion_place 基盤(DSP) 配賦計算フォーム DSPがメタモデルを提供する ⇓ ・プログラミング自由度は減る。 ・ドメインにあった高級概念を使える。 ・より高度なシステムを、より短期間で 構築できる。 拘束する
- 25. fusion_placeのメタモデル ＤＳＰは、ドメインにおけるニーズの共通性への洞察を踏まえ、適度に抽象化 されたドメインモデルを提供する。これがアプリケーションにとってはメタモ デルとなる。 （例）fusion_place のメタモデル（一部、要約） ディメンション 元帳 …多次元データ管理 汎用 式言語 テキスト式 (DSL) データアクセス制御 業務責任単位 入出力手段 フォーム定義（DSL）Excel-Link リンク領域定義 アクセス許可タイプ ワークフロー 元帳版 業務プロセス定義 業務プロセス 部署別 ワークスペース 締め管理
- 26. DDD in fusion_place ドメイン特化基盤（ＤＳＰ）の設計/開発は、通常のＤＤＤそのもの。ただしそ のドメインモデルはアプリケーションレイヤのメタモデルである。 マネジメントインテリ ジェンスシステム（*) の構築 多次元データの 加工・処理・提示 のしくみ 事象活動の領域 情報処理の領域 ドメインモデル B. DSPモデラー 問題領域 解決領域 モデリングパラダイム （OOPメタモデル） 問題領域 解決領域 Ａ. ドメインモデラー （＝コンサルタント） エンティティ 値クラス 元帳（キューブ） ディメンション フォーム フォーム定義(DSL) Java etc.. 基盤(言語・インフラ) テキスト式(DSL) （*) 計画／分析／報告を含む経営管理のため の情報処理システムの包括的呼称。フュージョ ンズが提唱。 拘束する
- 27. DDD + GP = DSP-driven Dev. Generative Programming は、ソフトウェア開発を、ドメインエンジニアリン グ（ソフトウェアファミリ開発）とアプリケーションエンジニアリング（ソフ トウェアインスタンス開発）に分かつ。ＤＤＤは前者だけでなく後者にも適用 することができる。 ＤＳＰレイヤ アプリケーション レイヤ ドメインモデル ユビキタス言語 ＤＳＬ モデリングパラダイム ドメインモデル ユビキタス言語 アプリケーション エンジニアリング ドメイン エンジニアリング 下位層のドメインモデルが 上位層にとってのモデリングの 枠組みを提供する。
- 29. 本当に終わり