【公開】第11回ドメイン駆動設計勉強会の発表資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka

DDD読書会@大阪の最終回に参加してきた。
LT資料と合わせて感想をメモ。

【元ネタ】
ドメイン駆動設計LT会（DDD読書会@大阪の最終回） - ドメイン駆動設計(DDD)読書会@大阪 | Doorkeeper

vol11_20140713_lightning_talks · dddosaka/reading_ddd_report Wiki

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

第10回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索

第7回ドメイン駆動設計勉強会の感想　#dddosaka: プログラマの思索

第6回ドメイン駆動設計読書会の感想: プログラマの思索

第４回ドメイン駆動設計読書会の感想: プログラマの思索

オブジェクト指向設計の４つの流派からドメイン駆動設計へ: プログラマの思索

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場

[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場

[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場

【1】DDD読書会@大阪に参加して良かったと思う。
10年前からオブジェクト指向設計の本の大半は読んできたから、「ドメイン駆動設計」の中身もこんな感じだろう、と自分勝手に思い込んでいたが、良い意味でたくさん裏切られた。
「ドメイン駆動設計」に関する自分の理解が浅かったと思う。

「ドメイン駆動設計」は、特定の業務に関するモデリングのパターンではなく、モデリング技術そのもののパターンだ。
たとえば、第4部の戦略的設計は、大規模システム設計に関する設計技術そのもののモデリングパターンだ。
特に、設計方法だけでなく、複数チームの編成や体制に関わるノウハウはすごく役立つ。

【2】ドメイン駆動設計が従来のナイーブなオブジェクト指向設計と違う箇所は、まず、サービスクラスや仕様クラスにあると思う。

手続きそのものや、ビジネスルールや制約そのものもオブジェクトにしてしまう。
これらのオブジェクトはステートレスだが、オブジェクトにした方がプログラムはスッキリする。
また、サービスや仕様クラスをインターフェイスにして実装クラスを継承させれば、ポリモルフィズムを実現できるので、機能追加もやりやすい。

さらに、サービスや仕様クラスが含まれる「コアドメイン」を「抽象化されたコア」へ蒸留して、機能の実現はポリモルフィズムで多様化するように実装すれば、DDDの理想郷である「着脱可能なコンポーネントのフレームワーク」になる。

【3】「ドメイン駆動設計」「UMLモデリングの本質」「SysML/UMLによるシステムエンジニアリング入門」の本を読み漁っていると、深いモデルには「権利」という概念が自然に現れることに気づいた。
公開資料では、下記4つの例を出してみた。

【例1】貨物輸送システムと船荷証券
【例2】利息計算と発生主義会計
【例3】鉄道の自動改札システムの乗車権
【例4】レンタカーの組込装置での車の使用権

権利という概念は何故必要なのか？
権利は何かを受け取る権利があるので、資産になる。
つまり、権利は売れる。

鉄道の切符、航空券、ホテルの予約券はいずれも、何らかの権利を意味する。
そして、権利に種類をつければ、色んなビジネスができる。
切符は、定期券やICカード、プリペイドカードなどで販売できる。
飛行機の座席、ホテルの部屋は、グレードによって料金体系を変えて、数多くの人にリーチして販売できる。

権利は論理的概念なので、基本は物理的制限がない。
だから、ネット販売と相性が良い。
楽天も、ECサイトだけでなくホテル・旅館のWebサイトも販売している理由はそこにあるのだろう。

但し、権利に個数の制限がある場合、そのモデルは在庫管理のモデルに似てくる。
権利の予約は在庫引当の機能と同じ。
鉄道の座席、飛行機の座席、ホテルの部屋の個数は無限ではないから、予約したら、その権利は引当されて、他の人は予約できなくなる。

在庫引当のロジックの実装は、先勝方式による排他制御などの特有のロジックがあり、それなりに深い技術も必要とする。
排他制御のロジックは「汎用サブドメイン」「凝集化されたメカニズム」に相当するだろう。

【3】ERPのフィットギャップ分析にドメイン駆動設計が使えないか、というアイデアもある。

ERPの機能分析にドメイン駆動設計が使えないか #dddosaka: プログラマの思索

色々試してみたい。

【追記】
懇親会で、@hidenorigotoさんからインスピレーションを受ける言葉をたくさんもらったのでメモ。

akipiiさんはTwitterを使っています: "#dddosaka 昨夜は@hidenorigotoさんからインスピレーションを受ける言葉をたくさんもらった。メモの一部を公開。「DDDの仕様クラスやサービスクラスはオブジェクトからメソッドを剥がすモデリング技法。それによって、プログラムがかなりスッキリする」"

akipiiさんはTwitterを使っています: "#dddosaka 昨夜は@hidenorigotoさんの言葉のメモ。「DDDのユビキタス言語は謎。「ユビキタス」という言葉は外した方がいい。ユビキタス言語を声に出して、ユーザと会話できるか。モデルから業務(暗黙知、ビジネスルール)が思い浮かべられるか。」"

akipiiさんはTwitterを使っています: "#dddosaka 昨夜は@hidenorigotoさんの言葉のメモ。「PHPのドメイン駆動設計は、Javaのそれと相性が良い。Javaのやり方がそのまま適用できる。Rubyは、Javaのやり方がそのまま当てはまらない。Javaのコードで書くとRubyらしくなくなる(らしい)」"