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

仙台で行われたレッツゴーデベロッパーZERO ONEで登壇した資料です。

Transcript

1. ドメインモデルのつくり方 2019/09/14 レッツゴーデベロッパーZERO ONE 末並 晃 @a_suenami
2. 自己紹介 • 末並 晃 @a_suenami • 生息している界隈: DDDとか、TDDとか、RDBとか • お仕事で使ってる技術スタック: Rails, React, 最近 Java とかも 少々 • 好きな RDBMS: PostgreSQL • 好きな制約: チェック制約 • 好きな焼肉の部位: ハラミ • 好きな（ｒｙ
3. インターネット上での立場
4. インターネット上での立場 ひたすら焼肉をタカられるという エンターテイメントをインターネットに提供し ています。 （焼肉を奢るとは言ってない）
5. インターネット上での立場 とはいえ、すえなみチャンスは わりと真面目に募集しています。 いろいろ教えてください。
6. 今日の話
7. その前に
8. 今日の後半の内容
9. モブモデリング
10. すえなみチャンスのドメインモデルを つくってみよう
11. すえなみチャンスとは • 一番素朴なモデル a-suenami つよい人 なんか教える
12. いろいろな方向性 • コミュニティ • ナレッジ共有 • 焼肉屋検索 • etc
13. 後半戦への諸注意 • 今日は実際の業務におけるモデリングじゃないので、とりあえず 自分が興味のあるコンテキストで考えてもらってよいです。 ◦ たとえばコンテキストを絞れば、等価交換だったり、マッチング だったり、情報共有やコラボレーションだったりしますよね。 • すえなみチャンスというものも僕が勝手にやってるだけのものな ので、都合よく捉えてもらっても大丈夫です。 ◦ 厳密にやりたいのであれば僕をドメインエキスパートと見なし ていただいてももちろん大丈夫です。 • というのが、後半戦なのでそれを念頭に話を聞いてもらいつつ、 ユビキタス言語になりそうな単語が思いついたらお手元の付箋に ガシガシ書いていってください。 ◦ 講演後にホワイトボードに貼って共有します。
14. ヒント的なもの • 最近流行ってる技術の追跡や検索 • 強い人たちと技術領域の関連やスコアリング • 焼肉屋の情報と予算感 ◦ 予約とかも • オンラインすえなみチャンス？ • 匿名質問サービスやらオンラインサロンやら
15. というわけで、本題
16. 本発表のモチベーション
17. 本発表のモチベーション • 実装技術に依存しない形でドメインモデルとは何だったのかとい う解説をし、モデリングそのものの重要性を伝えたい。 ◦ DDD本は実装パターンも多く紹介されているが、本質はそこ でなく語彙の発見とモデルの構築プロセスだと考えているた め。 ◦ （実装技術の否定ではない。念のため。） • 事業の意思決定者（DDD本でいうドメインエキスパート）とどのよ うにコラボレーションしていくかについて議論を深めてみたい。 （注意）実装技術に非依存とは言うものの、基本的には DDD本でエリック・エヴァンス氏が推奨している通り、オブ ジェクトモデリングパラダイムは前提とし、その実装としてクラスベースオブジェクト指向の（パラダイムを持つ）プ ログラミング言語が選定されることを前提とする。
18. というわけで、 基本的に技術的な話はしません。 （たまに出てくるかもですがご容赦）
19. DDD本を適宜引用はしますが 僕が普段やってる or これからやろうとして ることの紹介的な意味合いもあり 多分に経験則です。
20. モデルとは
21. https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
22. モデルとは？ https://ja.wikipedia.org/wiki/統一モデリング言語
23. モデルとは？
24. モデルとは？ https://eng-etymo.com/archives/829#toc4
25. 解決したい問題領域から 必要だと思われる情報を抽出して （逆に不要だと思われる情報を捨て） 記号化、可視化したもの
26. 例: 地図 • 方角、距離、面積などのあらゆ る変数があるなか、それを正 確に表現できているのは地球 儀のみ ◦ それでも完全に正確とは言 えない • メルカトル図法、正距方位図法 など、目的に応じてさまざまな 図法がある
27. 例: 連立方程式
28. モデルの世界と現実の世界
29. ドメインモデルとは
30. ドメイン駆動設計とドメインモデル 中心にあるのは「ユビキタス言語」と「モデル駆動設計」 「エリック・エヴァンスのドメイン駆動設計」 冒頭
31. ユビキタス言語とモデル駆動設計 • ドメインエキスパートと開発者の間の語彙の亀裂をなくし、翻訳の コストと誤解のリスクを防ぎ、より深い洞察へたどりつくための手 法およびその結果として出来上がった語彙のことをエリック・エ ヴァンスはユビキタス言語と呼んだ。 • また、分析モデルと設計モデルを分けず、単一のモデルで両方の 営みを実現する手法をモデル駆動設計と呼び、ユビキタス言語と 並び DDD 本の中心的な主張となっている。
32. 責務のレイヤー • DDD本 第16章「大規模な構造」の一節 「エリック・エヴァンスのドメイン駆動設計」 第16章「大規模な構造」
34. 安定依存の原則 • “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.” ◦ 「パッケージ間の依存関係の設計は、安定性のある方向に向 かわなければならない。パッケージはより安定したパッケージ に依存すべきだ。」 • ここでいう「安定性」は変更難易度のことを指すので極めて技術 的な概念と言えるが、エリック・エヴァンスが責務のレイヤーで いっている概念上のレイヤーもそのドメインにおいてより安定して いるもの・所与としているものへの依存と捉えられるのではない か。
35. ドメインモデルがもたらすもの（私見） ドメインモデル 共通の語彙 モデルと実装の一致 ドメインの構造
36. ドメインモデルがもたらすもの（私見） ドメインモデル 共通の語彙 モデルと実装の一致 ドメインの構造 今日の話のスコープ この2つは技術的な語 彙なしで洗練させていく ことが可能
37. ドメインモデルと ユビキタス言語のつくり方
38. ドメインモデルの構築で意識すること • 普段のコミュニケーションで使われる単語に意識を向ける。 ◦ 名詞、動詞、形容詞などは問わない。 ◦ この時点でとにかくたくさんの語彙をリストアップできると可能 性が広がる。 • 多義語、同義語が観測された場合はコンテキスト境界の可能性 を考える。 • 最初から完璧なモデルを目指さない。 ◦ UI ベースで考えやすい人は UI ベースで、DB のテーブルやカ ラムからのほうが考えやすい人はそれをベースにすればよ い。
39. 意識を向けたい対象
40. ドメインモデルの構築で意識すること • 同時に使われるものの集まりから計算方法や判断方法を見いだ せる可能性が高い。 ◦ 例: 料金計算に商品や注文をまるごと必要とはしない • 同時に変更されたり同時に削除されたりするものの集まりからイ ベントや状態遷移、もっと上位のユースケースを見いだせる可能 性が高い。 • 実体の属性としてのあり方に捉われすぎないほうがよい。 ◦ ここでいう「実体の属性」というのは、ER モデルでいう Entity やリレーショナルモデルでいう関数従属性のこと。
41. 意識を向けたい対象 • 計算方法 • 判断、条件 • イベント、状態遷移 • 上記の事柄の依存の方向
42. 計算方法の探し方 • いくつかの値を受け取り、別の値を導出するもの ◦ 実体（エンティティ）に捉われないほうが依存する対象を抑えら れる • 意識を向けるとよい単語 ◦ 「計算」「アルゴリズム」「ロジック」 • ある計算が別の計算に依存することはあり、より一般的なほうを 依存されるように考えるとよい。 ◦ 例: 料金計算 → 消費税込金額計算
43. 判断条件の探し方 • いくつかの値を受け取り、次のアクション等の判断結果を返すも の • マニュアルオペレーションも含めてユビキタス言語になると好まし い。 ◦ キャンセル可否条件、申し込み受付可否条件 • 意識を向けるとよい単語 ◦ 「条件」「〜の場合」 • 実装上は判断は特別な計算と捉えることもできる。 ◦ 計算の結果が真偽もしくは何らかの列挙型である場合、それ は判断であると考えられる。
44. イベントと状態遷移の探し方 • あるイベントによって次にやるべきことが決定し、それを待つ、あ るいは次の誰かに通知するとき、そのイベントとその前後の状態 はユビキタス言語になるべきである。 ◦ 本人確認: 本人確認待ち → 本人確認済み ◦ 出荷指示: 在庫引当済み → 出荷待ち • 注意したほうがよい点 ◦ 元に戻すということはあり得るのか（誤操作など） ◦ ある特定の状態が特別な意味や文脈を持つ場合、別の語彙 とするか、コンテキスト境界の可能性を考える ▪ 例: 公開済み記事
45. 依存の方向の検討 • 依存の方向は安定依存の原則と同様、変わりにくいものに依存 の方向を向けていくのがよい。 • 安定していると判断しやすいもの ◦ 事業上所与としているもの、たとえば安価に外部から仕入れ てこれるもの ◦ 社会通念上一般的な概念（通貨、時間・時刻、法で定められ ているもの、等） • 変わりやすいもの ◦ 競争優位性となる部分 ◦ 高速なPDCAを必要とするもの
46. 依存の方向の検討（例） 割引計算 料金計算 消費税込金額計算
47. 依存の方向の検討 • レイヤー数に制限はないが、3階層か4階層くらいがよいのではな いかとエリック・エヴァンス氏は言っていた気がする。 • 最初は自分たちでレイヤーを見出すのではなく、DDD本にある 「能力」「業務」「意思決定支援」をそのままフレームワークとして 使うのもよい。 ◦ これによってコンテキスト境界が見いだされることもある。 ◦ 例: 「在庫」は業務か、能力か
48. ここまでのまとめ • ドメインモデルとはドメインオブジェクトの構造であり、ドメインオブ ジェクトの名前はユビキタス言語になっていると好ましい。 • モデルを構築する場合、究極的には「ドメインエキスパートとちゃ んとコミュニケーションしよう」としかならない。 ◦ が、それだとつらい。もうちょっと秘伝のタレみたいなの欲しい よね。 • 「計算方法」「判断・条件」「イベント・状態遷移」とそれらの依存の 方向に着目することで、ドメインモデル構築の足がかりになるので はないか。
49. モブモデリング