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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 今日の話
   

   View Slide

7. その前に
   

   View Slide

8. 今日の後半の内容
   

   View Slide

9. モブモデリング
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. というわけで、本題
    

    View Slide

16. 本発表のモチベーション
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

20. モデルとは
    

    View Slide

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

    View Slide

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

    View Slide

23. モデルとは？
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. 例: 連立方程式
    

    View Slide

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

    View Slide

29. ドメインモデルとは
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. View Slide

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.”
    ○ 「パッケージ間の依存関係の設計は、安定性のある方向に向
    かわなければならない。パッケージはより安定したパッケージ
    に依存すべきだ。」
    ● ここでいう「安定性」は変更難易度のことを指すので極めて技術
    的な概念と言えるが、エリック・エヴァンスが責務のレイヤーで
    いっている概念上のレイヤーもそのドメインにおいてより安定して
    いるもの・所与としているものへの依存と捉えられるのではない
    か。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

39. 意識を向けたい対象
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

49. モブモデリング
    

    View Slide