ドメインモデルのつくり方 #5000dai

Slide 1

Slide 1 text

ドメインモデルのつくり方 2019/09/14 レッツゴーデベロッパーZERO ONE 末並晃 @a_suenami

Slide 2

Slide 2 text

自己紹介 ● 末並晃 @a_suenami ● 生息している界隈: DDDとか、TDDとか、RDBとか ● お仕事で使ってる技術スタック: Rails, React, 最近 Java とかも少々 ● 好きな RDBMS: PostgreSQL ● 好きな制約: チェック制約 ● 好きな焼肉の部位: ハラミ ● 好きな（ｒｙ

Slide 3

Slide 3 text

インターネット上での立場

Slide 4

Slide 4 text

インターネット上での立場ひたすら焼肉をタカられるというエンターテイメントをインターネットに提供しています。（焼肉を奢るとは言ってない）

Slide 5

Slide 5 text

インターネット上での立場とはいえ、すえなみチャンスはわりと真面目に募集しています。いろいろ教えてください。

Slide 6

Slide 6 text

今日の話

Slide 7

Slide 7 text

その前に

Slide 8

Slide 8 text

今日の後半の内容

Slide 9

Slide 9 text

モブモデリング

Slide 10

Slide 10 text

すえなみチャンスのドメインモデルをつくってみよう

Slide 11

Slide 11 text

すえなみチャンスとは ● 一番素朴なモデル a-suenami つよい人なんか教える

Slide 12

Slide 12 text

いろいろな方向性 ● コミュニティ ● ナレッジ共有 ● 焼肉屋検索 ● etc

Slide 13

Slide 13 text

後半戦への諸注意 ● 今日は実際の業務におけるモデリングじゃないので、とりあえず自分が興味のあるコンテキストで考えてもらってよいです。 ○ たとえばコンテキストを絞れば、等価交換だったり、マッチングだったり、情報共有やコラボレーションだったりしますよね。 ● すえなみチャンスというものも僕が勝手にやってるだけのものなので、都合よく捉えてもらっても大丈夫です。 ○ 厳密にやりたいのであれば僕をドメインエキスパートと見なしていただいてももちろん大丈夫です。 ● というのが、後半戦なのでそれを念頭に話を聞いてもらいつつ、ユビキタス言語になりそうな単語が思いついたらお手元の付箋にガシガシ書いていってください。 ○ 講演後にホワイトボードに貼って共有します。

Slide 14

Slide 14 text

ヒント的なもの ● 最近流行ってる技術の追跡や検索 ● 強い人たちと技術領域の関連やスコアリング ● 焼肉屋の情報と予算感 ○ 予約とかも ● オンラインすえなみチャンス？ ● 匿名質問サービスやらオンラインサロンやら

Slide 15

Slide 15 text

というわけで、本題

Slide 16

Slide 16 text

本発表のモチベーション

Slide 17

Slide 17 text

本発表のモチベーション ● 実装技術に依存しない形でドメインモデルとは何だったのかという解説をし、モデリングそのものの重要性を伝えたい。 ○ DDD本は実装パターンも多く紹介されているが、本質はそこでなく語彙の発見とモデルの構築プロセスだと考えているため。 ○ （実装技術の否定ではない。念のため。） ● 事業の意思決定者（DDD本でいうドメインエキスパート）とどのようにコラボレーションしていくかについて議論を深めてみたい。（注意）実装技術に非依存とは言うものの、基本的には DDD本でエリック・エヴァンス氏が推奨している通り、オブジェクトモデリングパラダイムは前提とし、その実装としてクラスベースオブジェクト指向の（パラダイムを持つ）プログラミング言語が選定されることを前提とする。

Slide 18

Slide 18 text

というわけで、基本的に技術的な話はしません。（たまに出てくるかもですがご容赦）

Slide 19

Slide 19 text

DDD本を適宜引用はしますが僕が普段やってる or これからやろうとしてることの紹介的な意味合いもあり多分に経験則です。

Slide 20

Slide 20 text

モデルとは

Slide 21

Slide 21 text

https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm

Slide 22

Slide 22 text

モデルとは？ https://ja.wikipedia.org/wiki/統一モデリング言語

Slide 23

Slide 23 text

モデルとは？

Slide 24

Slide 24 text

モデルとは？ https://eng-etymo.com/archives/829#toc4

Slide 25

Slide 25 text

解決したい問題領域から必要だと思われる情報を抽出して（逆に不要だと思われる情報を捨て）記号化、可視化したもの

Slide 26

Slide 26 text

例: 地図 ● 方角、距離、面積などのあらゆる変数があるなか、それを正確に表現できているのは地球儀のみ ○ それでも完全に正確とは言えない ● メルカトル図法、正距方位図法など、目的に応じてさまざまな図法がある

Slide 27

Slide 27 text

例: 連立方程式

Slide 28

Slide 28 text

モデルの世界と現実の世界

Slide 29

Slide 29 text

ドメインモデルとは

Slide 30

Slide 30 text

ドメイン駆動設計とドメインモデル中心にあるのは「ユビキタス言語」と「モデル駆動設計」「エリック・エヴァンスのドメイン駆動設計」冒頭

Slide 31

Slide 31 text

ユビキタス言語とモデル駆動設計 ● ドメインエキスパートと開発者の間の語彙の亀裂をなくし、翻訳のコストと誤解のリスクを防ぎ、より深い洞察へたどりつくための手法およびその結果として出来上がった語彙のことをエリック・エヴァンスはユビキタス言語と呼んだ。 ● また、分析モデルと設計モデルを分けず、単一のモデルで両方の営みを実現する手法をモデル駆動設計と呼び、ユビキタス言語と並び DDD 本の中心的な主張となっている。

Slide 32

Slide 32 text

責務のレイヤー ● DDD本第16章「大規模な構造」の一節「エリック・エヴァンスのドメイン駆動設計」第16章「大規模な構造」

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

安定依存の原則 ● “The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.” ○ 「パッケージ間の依存関係の設計は、安定性のある方向に向かわなければならない。パッケージはより安定したパッケージに依存すべきだ。」 ● ここでいう「安定性」は変更難易度のことを指すので極めて技術的な概念と言えるが、エリック・エヴァンスが責務のレイヤーでいっている概念上のレイヤーもそのドメインにおいてより安定しているもの・所与としているものへの依存と捉えられるのではないか。

Slide 35

Slide 35 text

ドメインモデルがもたらすもの（私見）ドメインモデル共通の語彙モデルと実装の一致ドメインの構造

Slide 36

Slide 36 text

ドメインモデルがもたらすもの（私見）ドメインモデル共通の語彙モデルと実装の一致ドメインの構造今日の話のスコープこの2つは技術的な語彙なしで洗練させていくことが可能

Slide 37

Slide 37 text

ドメインモデルとユビキタス言語のつくり方

Slide 38

Slide 38 text

ドメインモデルの構築で意識すること ● 普段のコミュニケーションで使われる単語に意識を向ける。 ○ 名詞、動詞、形容詞などは問わない。 ○ この時点でとにかくたくさんの語彙をリストアップできると可能性が広がる。 ● 多義語、同義語が観測された場合はコンテキスト境界の可能性を考える。 ● 最初から完璧なモデルを目指さない。 ○ UI ベースで考えやすい人は UI ベースで、DB のテーブルやカラムからのほうが考えやすい人はそれをベースにすればよい。

Slide 39

Slide 39 text

意識を向けたい対象

Slide 40

Slide 40 text

ドメインモデルの構築で意識すること ● 同時に使われるものの集まりから計算方法や判断方法を見いだせる可能性が高い。 ○ 例: 料金計算に商品や注文をまるごと必要とはしない ● 同時に変更されたり同時に削除されたりするものの集まりからイベントや状態遷移、もっと上位のユースケースを見いだせる可能性が高い。 ● 実体の属性としてのあり方に捉われすぎないほうがよい。 ○ ここでいう「実体の属性」というのは、ER モデルでいう Entity やリレーショナルモデルでいう関数従属性のこと。

Slide 41

Slide 41 text

意識を向けたい対象 ● 計算方法 ● 判断、条件 ● イベント、状態遷移 ● 上記の事柄の依存の方向

Slide 42

Slide 42 text

計算方法の探し方 ● いくつかの値を受け取り、別の値を導出するもの ○ 実体（エンティティ）に捉われないほうが依存する対象を抑えられる ● 意識を向けるとよい単語 ○ 「計算」「アルゴリズム」「ロジック」 ● ある計算が別の計算に依存することはあり、より一般的なほうを依存されるように考えるとよい。 ○ 例: 料金計算 → 消費税込金額計算

Slide 43

Slide 43 text

判断条件の探し方 ● いくつかの値を受け取り、次のアクション等の判断結果を返すもの ● マニュアルオペレーションも含めてユビキタス言語になると好ましい。 ○ キャンセル可否条件、申し込み受付可否条件 ● 意識を向けるとよい単語 ○ 「条件」「〜の場合」 ● 実装上は判断は特別な計算と捉えることもできる。 ○ 計算の結果が真偽もしくは何らかの列挙型である場合、それは判断であると考えられる。

Slide 44

Slide 44 text

イベントと状態遷移の探し方 ● あるイベントによって次にやるべきことが決定し、それを待つ、あるいは次の誰かに通知するとき、そのイベントとその前後の状態はユビキタス言語になるべきである。 ○ 本人確認: 本人確認待ち → 本人確認済み ○ 出荷指示: 在庫引当済み → 出荷待ち ● 注意したほうがよい点 ○ 元に戻すということはあり得るのか（誤操作など） ○ ある特定の状態が特別な意味や文脈を持つ場合、別の語彙とするか、コンテキスト境界の可能性を考える ■ 例: 公開済み記事

Slide 45

Slide 45 text

依存の方向の検討 ● 依存の方向は安定依存の原則と同様、変わりにくいものに依存の方向を向けていくのがよい。 ● 安定していると判断しやすいもの ○ 事業上所与としているもの、たとえば安価に外部から仕入れてこれるもの ○ 社会通念上一般的な概念（通貨、時間・時刻、法で定められているもの、等） ● 変わりやすいもの ○ 競争優位性となる部分 ○ 高速なPDCAを必要とするもの

Slide 46

Slide 46 text

依存の方向の検討（例）割引計算料金計算消費税込金額計算

Slide 47

Slide 47 text

依存の方向の検討 ● レイヤー数に制限はないが、3階層か4階層くらいがよいのではないかとエリック・エヴァンス氏は言っていた気がする。 ● 最初は自分たちでレイヤーを見出すのではなく、DDD本にある「能力」「業務」「意思決定支援」をそのままフレームワークとして使うのもよい。 ○ これによってコンテキスト境界が見いだされることもある。 ○ 例: 「在庫」は業務か、能力か

Slide 48

Slide 48 text

ここまでのまとめ ● ドメインモデルとはドメインオブジェクトの構造であり、ドメインオブジェクトの名前はユビキタス言語になっていると好ましい。 ● モデルを構築する場合、究極的には「ドメインエキスパートとちゃんとコミュニケーションしよう」としかならない。 ○ が、それだとつらい。もうちょっと秘伝のタレみたいなの欲しいよね。 ● 「計算方法」「判断・条件」「イベント・状態遷移」とそれらの依存の方向に着目することで、ドメインモデル構築の足がかりになるのではないか。

Slide 49

Slide 49 text

モブモデリング