ドメイン駆動設計で気づいたこと 
〜権利の概念とERP分析への適用 
DDD読書会@大阪(最終回) 
2014/9/21 
あきぴー@XPJUG関⻄ 
copyright2014 akipii@XPJUG関西1
Agenda 
• まずは御礼 
• 問題意識 
• 深いモデルに辿り着くための仮説 
• 今後のテーマ 
• 戦略的設計のパターン 
• 今後やりたいこと 
copyright2014 akipii@XPJUG関西2
まずは御礼 
• DDD@⼤阪の勉強会に参加して良かった! 
• DDD本の凄さをようやく理解できた 
• 特定の業務の事例集ではなく、モデリング技術そのもののパターン集 
• 「戦略的設計」の⼿法は、⼤規模システムの設計に適用できる 
• 自分の理解が浅かった 
• 過去のナイーブなオブジェクト指向設計とは違う 
• サービス/仕様Classの意図が分かった 
• ⼤規模システム設計には、チーム編成の問題も加わる点はよく分かる 
• 他⼈の議論を聞いて、気付きが得られた 
• 一⼈で読んで勘違いしている部分があった 
• 事例が多いので読みやすく議論しやすい 
copyright2014 akipii@XPJUG関西3
問題意識 
• 深いモデルとは 
• ドメイン専門家の関⼼事と関連知識を表したモデル 
• 深いモデルになると、なぜ「会計」の概念が現れるのか? 
• 【例1】貨物輸送システム→船荷証券 
• 【例2】利息計算→発生主義会計 
• 深いモデルになると、なぜ「権利」の概念が出てくるのか? 
• 【例3】鉄道の自動改札システム→鉄道の乗⾞権 
• 【例4】レンタカーのオンボード組込装置→⾞の使用権 
copyright2014 akipii@XPJUG関西4
【例1】貨物輸送システムと船荷証券 
【船荷証券=貨物の引受・受取を証明する権利書】 
【仕訳の例】 
貨物輸送の契約後に、船荷証券を受取:未着品//買掛⾦ 
貨物到着後に、船荷証券を引換に貨物受取:仕入//未着品 
copyright2014 akipii@XPJUG関西5 
DDD本(P.181)では、クラス図に 
船荷証券クラスが突然出てくる。 
モデリングの過程を書いて欲しかっ 
た。
【例2】利息計算と発生主義会計 
⽇々の仕訳は、仕訳帳に 
記録される。 
過去は⼿作業だったが現 
在はシステム化されているの 
が普通。 
DDD本(P.306)では、発生主義会計の観点から経過勘定科目(仕訳1,2)が出てくる。 
【仕訳1】本⽇、銀⾏からの借入⾦の利息が当座預⾦から引落された:⽀払利息//当座預⾦ 
【仕訳2】本⽇、普通預⾦の利息800円が通帳に記入された:普通預⾦//受取利息 
copyright2014 akipii@XPJUG関西6
【例3】鉄道の自動改札システムの乗⾞権 
copyright2014 akipii@XPJUG関西7 
【コンテキスト】 
自動改札システムのスコープは、「乗客が正し 
い運賃を⽀払ったか否かを確認する」だけの機 
能とする。(『UMLモデリングの本質』P.89) 
【乗⾞権=利用者が電⾞に乗る権利、着席権=座席に座る権利】 
①乗⾞権や座席券は、保持者の名前まで管理しない時がある。 
②権利の供与や契約なので、様々なビジネスが発生する。 
(定期券・回数券・プリペイドカード・グリーン席・早期得割etc.) 
③権利には状態があり放棄する権利も含まれる。(使用前、使用中、使用済)
【例4】レンタカーの組込装置での⾞の使用権 
【コンテキスト】 
・レンタカー会社が、レンタカーに「オンボード組込装置」を導入する開発案件。 
・オンボード組込装置は「利用客のICカードを読み込んで、⾞の予約状況を予約シ 
ステムに確認でき、利用者が乗る⾞のキーの状態を記憶する」機能とする。 
(『SysML/UMLによるシステムエンジニアリング入門』P.123) 
オンボード組込装置 
(イメージ) 
【使用権=レンタカーを使う権利】 
利用者はICカードをオンボード組 
込装置に読み込ませる 
→予約システムに問合せて、利 
用者の使用権をチェックする 
→⾞の盗難防止機能を解除す 
る 
copyright2014 akipii@XPJUG関西8
深いモデルに辿り着くための仮説 
• 仮説1:深いモデルの鍵は、商流の発⾒にある 
• 商流とは、カネの流れ(仕訳etc.) 
• 例:貨物の輸送の責任が移動する時に、船荷証券がやり取りされる 
• 例:利息が確定されたタイミングで、仕訳が発生する 
• 仮説2:深いモデルの鍵は、「権利」と「義務」の発⾒にある 
• 権利は資産なので、何かを受け取る権利がある 
• 義務は負債なので、何かを⽀払う義務がある 
• 「権利」になるモノは売れる 
• 鉄道の座席に座る権利(乗⾞券)→例:プリベートICカード 
• レンタカーを借りる権利(⾞の使用権)→例:カー・シェア 
• 権利の個数に制限がある場合、在庫管理のように扱う 
• 在庫引当は「権利の予約」に相当 
• 航空券予約システムやホテル予約システムは在庫管理システムと同じ 
copyright2014 akipii@XPJUG関西9
今後のテーマ 
• ERPのフィットギャップ分析にドメイン駆動設計を適用したい 
• 現状:業務システム構築はERPの導入が普通 
• スクラッチ開発するには、ユーザ企業に要件定義やマネジメント⼒がない 
• ベンダーの⽀援を受けた方が、導入や保守も外注できる 
• 課題:ERPの機能は複雑で膨⼤なので、理解しづらい 
• 自社の業務に、ERPのどの機能が当てはまるのか? 
• 業務の効率化の効果を得るには、どうすればよいのか? 
• 動機:ドメイン駆動設計のパターンを使って、ERPの中⾝を理解 
するのに役⽴てられないか? 
• 現場業務とERPのフィットギャップ分析に使う 
• ERPの設計思想を解読するために使う 
• オープンソースERPの導入・運用・開発に役⽴てられないか? 
copyright2014 akipii@XPJUG関西10
戦略的設計のパターン 
• 現場のERPのフィットギャップ分析に使えそうなパターン 
(どのパターンも、設計方針とチーム編成に関わる) 
① コンテキスト境界、コンテキストマップ 
② 【例4】顧客/供給者チーム→サブシステム間の依存関係 
③ 【例5】腐敗防止層→ラッピングという外部接続 
④ 公開ホストサービス→SOA連携、EB連携など 
⑤ コアドメイン→SWプロダクトライン 
⑥ 汎用サブドメイン→ワークフローエンジンなど 
⑦ 凝集化されたメカニズム→グラフ計算、MRPアルゴリズム 
⑧ 着脱可能コンポーネントのフレームワーク→DDDの理想郷 
【オージス総研のWeb記事は、DDD本の概要が的確に短くまとめられている。お勧め!】 
[ 技術講座] Domain-Driven Designのエッセンス第3回|オブジェクトの広場 
https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap3.html 
copyright2014 akipii@XPJUG関西11
戦略的設計のパターンの例 
copyright2014 akipii@XPJUG関西12 
【例4】顧客/供給者チーム 
【例5】腐敗防止層 
①データの流れは、輸送システム 
(供給者)→分析システム(顧客)。 
②顧客システム側のチームが供給 
者システム側よりも政治的に強い 
時に有効。 
③顧客システム側のチームが政治 
的に弱い場合、順応者・別々の 
道・腐敗防止層のパターンを使う。 
①レガシーシステムとシステム連携す 
る場合、データ連携するための腐敗 
防止層を作る。 
例:EDI連携、EB連携、バッチ連 
携など 
②レガシーシステム側に外部接続 
APIが作れるならば、公開ホストサー 
ビスを使う。 
例: SOA連携、SOAP連携、 
REST API、JSONPなど
今後やりたいこと 
1. DDD本の「第4部戦略的設計」を輪読したい 
 基幹系業務システムの開発経験があれば理解しやすい 
 このノウハウがあれば、開発はもっと楽になったかもしれない 
2. 戦略的DDDをエンタープライズアーキテクチャに適用した 
事例の論⽂を輪読したい 
ノルウェーの⼤⼿石油/ガス会社StatOil社の事例 
① EAの改善に「戦略的デザイン」パターンを適用した事例 
② ERPなどの商用パッケージ製品の評価に「戦略的デザイン」パターンを 
適用した事例 
【DDD本を紹介しているオージス総研のWeb記事にリンクがある】 
①Architectural Improvement by use of Strategic Level Domain-Driven Design 
http://domaindrivendesign.org/practitioner_reports/landre_einar_2006_part1.html 
②Using Domain-Driven Design to Evaluate Commercial Off-The-Shelf software 
http://domaindrivendesign.org/practitioner_reports/landre_einar_2006_part2.html 
copyright2014 akipii@XPJUG関西13
参加者の皆様、 
議論して下さって 
ありがとう 
ございました 
copyright2014 akipii@XPJUG関西14

DDD読書会@大阪(最終回)のLT資料「ドメイン駆動設計で気づいたこと~権利の概念とERP分析への適用」 #dddosaka

  • 1.
  • 2.
    Agenda • まずは御礼 • 問題意識 • 深いモデルに辿り着くための仮説 • 今後のテーマ • 戦略的設計のパターン • 今後やりたいこと copyright2014 akipii@XPJUG関西2
  • 3.
    まずは御礼 • DDD@⼤阪の勉強会に参加して良かった! • DDD本の凄さをようやく理解できた • 特定の業務の事例集ではなく、モデリング技術そのもののパターン集 • 「戦略的設計」の⼿法は、⼤規模システムの設計に適用できる • 自分の理解が浅かった • 過去のナイーブなオブジェクト指向設計とは違う • サービス/仕様Classの意図が分かった • ⼤規模システム設計には、チーム編成の問題も加わる点はよく分かる • 他⼈の議論を聞いて、気付きが得られた • 一⼈で読んで勘違いしている部分があった • 事例が多いので読みやすく議論しやすい copyright2014 akipii@XPJUG関西3
  • 4.
    問題意識 • 深いモデルとは • ドメイン専門家の関⼼事と関連知識を表したモデル • 深いモデルになると、なぜ「会計」の概念が現れるのか? • 【例1】貨物輸送システム→船荷証券 • 【例2】利息計算→発生主義会計 • 深いモデルになると、なぜ「権利」の概念が出てくるのか? • 【例3】鉄道の自動改札システム→鉄道の乗⾞権 • 【例4】レンタカーのオンボード組込装置→⾞の使用権 copyright2014 akipii@XPJUG関西4
  • 5.
    【例1】貨物輸送システムと船荷証券 【船荷証券=貨物の引受・受取を証明する権利書】 【仕訳の例】 貨物輸送の契約後に、船荷証券を受取:未着品//買掛⾦ 貨物到着後に、船荷証券を引換に貨物受取:仕入//未着品 copyright2014 akipii@XPJUG関西5 DDD本(P.181)では、クラス図に 船荷証券クラスが突然出てくる。 モデリングの過程を書いて欲しかっ た。
  • 6.
    【例2】利息計算と発生主義会計 ⽇々の仕訳は、仕訳帳に 記録される。 過去は⼿作業だったが現 在はシステム化されているの が普通。 DDD本(P.306)では、発生主義会計の観点から経過勘定科目(仕訳1,2)が出てくる。 【仕訳1】本⽇、銀⾏からの借入⾦の利息が当座預⾦から引落された:⽀払利息//当座預⾦ 【仕訳2】本⽇、普通預⾦の利息800円が通帳に記入された:普通預⾦//受取利息 copyright2014 akipii@XPJUG関西6
  • 7.
    【例3】鉄道の自動改札システムの乗⾞権 copyright2014 akipii@XPJUG関西7 【コンテキスト】 自動改札システムのスコープは、「乗客が正し い運賃を⽀払ったか否かを確認する」だけの機 能とする。(『UMLモデリングの本質』P.89) 【乗⾞権=利用者が電⾞に乗る権利、着席権=座席に座る権利】 ①乗⾞権や座席券は、保持者の名前まで管理しない時がある。 ②権利の供与や契約なので、様々なビジネスが発生する。 (定期券・回数券・プリペイドカード・グリーン席・早期得割etc.) ③権利には状態があり放棄する権利も含まれる。(使用前、使用中、使用済)
  • 8.
    【例4】レンタカーの組込装置での⾞の使用権 【コンテキスト】 ・レンタカー会社が、レンタカーに「オンボード組込装置」を導入する開発案件。 ・オンボード組込装置は「利用客のICカードを読み込んで、⾞の予約状況を予約シ ステムに確認でき、利用者が乗る⾞のキーの状態を記憶する」機能とする。 (『SysML/UMLによるシステムエンジニアリング入門』P.123) オンボード組込装置 (イメージ) 【使用権=レンタカーを使う権利】 利用者はICカードをオンボード組 込装置に読み込ませる →予約システムに問合せて、利 用者の使用権をチェックする →⾞の盗難防止機能を解除す る copyright2014 akipii@XPJUG関西8
  • 9.
    深いモデルに辿り着くための仮説 • 仮説1:深いモデルの鍵は、商流の発⾒にある • 商流とは、カネの流れ(仕訳etc.) • 例:貨物の輸送の責任が移動する時に、船荷証券がやり取りされる • 例:利息が確定されたタイミングで、仕訳が発生する • 仮説2:深いモデルの鍵は、「権利」と「義務」の発⾒にある • 権利は資産なので、何かを受け取る権利がある • 義務は負債なので、何かを⽀払う義務がある • 「権利」になるモノは売れる • 鉄道の座席に座る権利(乗⾞券)→例:プリベートICカード • レンタカーを借りる権利(⾞の使用権)→例:カー・シェア • 権利の個数に制限がある場合、在庫管理のように扱う • 在庫引当は「権利の予約」に相当 • 航空券予約システムやホテル予約システムは在庫管理システムと同じ copyright2014 akipii@XPJUG関西9
  • 10.
    今後のテーマ • ERPのフィットギャップ分析にドメイン駆動設計を適用したい • 現状:業務システム構築はERPの導入が普通 • スクラッチ開発するには、ユーザ企業に要件定義やマネジメント⼒がない • ベンダーの⽀援を受けた方が、導入や保守も外注できる • 課題:ERPの機能は複雑で膨⼤なので、理解しづらい • 自社の業務に、ERPのどの機能が当てはまるのか? • 業務の効率化の効果を得るには、どうすればよいのか? • 動機:ドメイン駆動設計のパターンを使って、ERPの中⾝を理解 するのに役⽴てられないか? • 現場業務とERPのフィットギャップ分析に使う • ERPの設計思想を解読するために使う • オープンソースERPの導入・運用・開発に役⽴てられないか? copyright2014 akipii@XPJUG関西10
  • 11.
    戦略的設計のパターン • 現場のERPのフィットギャップ分析に使えそうなパターン (どのパターンも、設計方針とチーム編成に関わる) ① コンテキスト境界、コンテキストマップ ② 【例4】顧客/供給者チーム→サブシステム間の依存関係 ③ 【例5】腐敗防止層→ラッピングという外部接続 ④ 公開ホストサービス→SOA連携、EB連携など ⑤ コアドメイン→SWプロダクトライン ⑥ 汎用サブドメイン→ワークフローエンジンなど ⑦ 凝集化されたメカニズム→グラフ計算、MRPアルゴリズム ⑧ 着脱可能コンポーネントのフレームワーク→DDDの理想郷 【オージス総研のWeb記事は、DDD本の概要が的確に短くまとめられている。お勧め!】 [ 技術講座] Domain-Driven Designのエッセンス第3回|オブジェクトの広場 https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap3.html copyright2014 akipii@XPJUG関西11
  • 12.
    戦略的設計のパターンの例 copyright2014 akipii@XPJUG関西12 【例4】顧客/供給者チーム 【例5】腐敗防止層 ①データの流れは、輸送システム (供給者)→分析システム(顧客)。 ②顧客システム側のチームが供給 者システム側よりも政治的に強い 時に有効。 ③顧客システム側のチームが政治 的に弱い場合、順応者・別々の 道・腐敗防止層のパターンを使う。 ①レガシーシステムとシステム連携す る場合、データ連携するための腐敗 防止層を作る。 例:EDI連携、EB連携、バッチ連 携など ②レガシーシステム側に外部接続 APIが作れるならば、公開ホストサー ビスを使う。 例: SOA連携、SOAP連携、 REST API、JSONPなど
  • 13.
    今後やりたいこと 1. DDD本の「第4部戦略的設計」を輪読したい 基幹系業務システムの開発経験があれば理解しやすい このノウハウがあれば、開発はもっと楽になったかもしれない 2. 戦略的DDDをエンタープライズアーキテクチャに適用した 事例の論⽂を輪読したい ノルウェーの⼤⼿石油/ガス会社StatOil社の事例 ① EAの改善に「戦略的デザイン」パターンを適用した事例 ② ERPなどの商用パッケージ製品の評価に「戦略的デザイン」パターンを 適用した事例 【DDD本を紹介しているオージス総研のWeb記事にリンクがある】 ①Architectural Improvement by use of Strategic Level Domain-Driven Design http://domaindrivendesign.org/practitioner_reports/landre_einar_2006_part1.html ②Using Domain-Driven Design to Evaluate Commercial Off-The-Shelf software http://domaindrivendesign.org/practitioner_reports/landre_einar_2006_part2.html copyright2014 akipii@XPJUG関西13
  • 14.
    参加者の皆様、 議論して下さって ありがとう ございました copyright2014 akipii@XPJUG関西14