Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

0b40b09ee30366ddfe68070d94d7ee3f?s=47 Akira Suenami
September 14, 2019

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

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

0b40b09ee30366ddfe68070d94d7ee3f?s=128

Akira Suenami

September 14, 2019
Tweet

Transcript

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

  2. 自己紹介 • 末並 晃 @a_suenami • 生息している界隈: DDDとか、TDDとか、RDBとか • お仕事で使ってる技術スタック:

    Rails, React, 最近 Java とかも 少々 • 好きな RDBMS: PostgreSQL • 好きな制約: チェック制約 • 好きな焼肉の部位: ハラミ • 好きな(ry
  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章「大規模な構造」

  33. None
  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. モブモデリング