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 ● 好きな制約: チェック制約 ● 好きな焼肉の部位: ハラミ ● 好きな(ry

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

モブモデリング