システム設計の中でドメインモデルの役割を体感する / the Place of Domain Model in System Design

Transcript

1. Copyright levii Inc. All rights reserved. システム設計の中での ドメインモデルの役割を体感 る 株式会社レヴィ 2019/12/14 レガシーをぶっつぶ 。現場でDDD2！ #genbadeDDD
2. Copyright levii Inc. All rights reserved. 2 萩原 利士成 @hagifoo 株式会社レヴィ 共同創業者 弓山 彬 @akiray03 株式会社レヴィ 共同創業者CTO 全体ファシリテーター
3. Copyright levii Inc. All rights reserved. 吉澤 良典 株式会社レヴィ 五十嵐 智 株式会社レヴィ スタッフ 大石 晃平 @tama_camp 株式会社PRECS 前原 孝輔 Yahoo 株式会社 小屋 州平 @yosu LAPRAS株式会社
4. Copyright levii Inc. All rights reserved. 宇宙開発 生ん システム設計の方法論 現場で鍛えあ 実行可能なノウハウ プロジェクトを成功に導 、 成功し続けられるチームへと変革する 株式会社レヴィ: チームに実践的なシステム設計の力を
5. ワーク: 自己紹介
6. Copyright levii Inc. All rights reserved. [10分] 各チームで自己紹介を ま ょう 以下を れ れ付箋に書いて他の参加者に見えるように机 に貼って い 山田 太郎 サーバサイド エンジニア oo年もののレ ガシーコード をリファクタ い DDDを周りに どうやって広 め らよい 知見 欲 い 名前、仕事内容 DDD で 解決 い課題 期待 ている と
7. システム設計とドメインモデル
8. Copyright levii Inc. All rights reserved. システムを作る ＝ コードを書 ？
9. Copyright levii Inc. All rights reserved. コードを書 システムを作る ギャップ
10. Copyright levii Inc. All rights reserved. コードを書 システムを作る DDD？
11. Copyright levii Inc. All rights reserved. コードを書 システムを作る DDDesign
12. Copyright levii Inc. All rights reserved. システム設計とは？
13. Copyright levii Inc. All rights reserved. システム設計とは？ ど まで システム設計なの ？
14. Copyright levii Inc. All rights reserved. システム ソースコード 14
15. Copyright levii Inc. All rights reserved. システム (ユーザー)インターフェース ソースコード 15
16. Copyright levii Inc. All rights reserved. ソフトウェアの核心は、 ドメインに関係した問題を ユーザのために解決 る 能力である。 それ以外の特徴はい れも、 どれほど重要 と ても、 の基本的な目的を支えるに す ない。
17. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード 17 ドメインは こっち
18. Copyright levii Inc. All rights reserved. 設計はシステムの内側 では 完結で ない
19. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード 19 システムの 正しさを作る システムを 正し 作る
20. Copyright levii Inc. All rights reserved. 正 とは何 ？
21. Copyright levii Inc. All rights reserved. ドメインの問題を解決で ていれば GOTO 文でもいいの？ ↓ Yes (の時もある)
22. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード 22 ドメイン (業務の) 変化 変化はシステムの外からやって る
23. Copyright levii Inc. All rights reserved. 変化の元となるドメイン知識を システムにどのように取り込む ？
24. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード 概念モデル 24
25. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード クラス ドメインモデル 25 概念モデル
26. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード クラス ドメインモデル 26 概念モデル ドメインモデル システムの外(ユーザーの関心) と システムの中(クラス設計) を繋 業務ドメインで扱う概念をモデル化 ステークホルダーとの認識を揃える
27. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード 概念モデル 27 業務フロー モデル
28. Copyright levii Inc. All rights reserved. システムの外 システム (ユーザー)インターフェース ソースコード 概念モデル 28 業務フロー モデル 今回は、業務フローモデルと概念モデルに着目 れらのモデルを使って実装対象「ドメイン」を把握 る と 今回のワークのゴール
29. Copyright levii Inc. All rights reserved. 理解い い点 ワークは100点ではない スタッフも全ては分 っていない 一緒にやってみま ょう！
30. ワークショップ説明
31. Copyright levii Inc. All rights reserved. ゴール • システムに対 る認識＝ドメイン知識を りあわ るコ ツ なんとな 身につ & 持ち帰って実践する ◦ ※スタッフ向 の参考資料も公開予定！ • 基本ルール ◦ ×パーフェクトなモデルを書 ◦ ◯ワーク参加者同士で認識を揃える
32. Copyright levii Inc. All rights reserved. やる と • ロールプレイを な ら 3 つのワークを行いま • 各テーブル とに以下のロールを設定 ◦ a) ナビゲーター: スタッフ ◦ b) ドメインエキスパート: スタッフ ◦ c) 開発チーム: 参加者のみな ん ◦ ※スタッフは真のドメインエキスパートではありま ん • 現場に帰っ ら？ ◦ スタッフ -> リアルな PO, ビジネスサイド
33. Copyright levii Inc. All rights reserved. ワークショップの流れ ワーク１ 業務フロー モデリング ワーク2 概念 モデリング ワーク3 振り返り
34. Copyright levii Inc. All rights reserved. ワークショップの流れ ワーク１ 業務フロー モデリング ワーク2 概念 モデリング ワーク3 振り返り • ふ ん行っている とを時系列で ヒアリング な ら情報を集める • 概念モデルを構築 る めの手 りを集めてい
35. Copyright levii Inc. All rights reserved. ワークショップの流れ ワーク１ 業務フロー モデリング ワーク2 概念 モデリング ワーク3 振り返り • 業務フローモデルの中 ら概念を 見つけ、それらの関係を整理 る • 似ている れど異なる概念を明ら に る • 手続 指向の業務フローモデル ら、オブジェクト指向の概念モデ ルに変換 る
36. Copyright levii Inc. All rights reserved. ワークショップの流れ ワーク１ 業務フロー モデリング ワーク2 概念 モデリング ワーク3 振り返り • 学び、気付 の整理 • ワークショップの改善に向 フィードバック
37. 状況設定
38. Copyright levii Inc. All rights reserved. 背景 • みな んは、Webサービスを開発 るロビィ社の開発 チームメンバーで 。 • のWebサービスには、ユーザー らの不具合報告や機 能追加の要望を受 付 る要望投稿の機能 実装 れて り、登録 れ 要望は、カスタマーサポートチーム (CSチーム) 中心となって優先順位付 を行って、対応 方針を決めていま 。 • 要望管理機能には、コメント機能や通知機能も実装 れ ていて、ユーザーとCSチームの間でコミュニケーショ ンを取る と で ていま 。
39. Copyright levii Inc. All rights reserved. 機能改善プロジェクト！ • 今回、要望管理機能を改善 るプロジェクトをCSチー ムと一緒に立 上 る とになりま 。 • いまのシステムは、外部ベンダーに委託 て作られ も ので...（意訳：コード読め もん ゃな っ ）、改修 ではな 、新 にシステムを立 上 る とになりま 。 • 新 いシステムでどのような機能を実現 ればよいの 、実際の利用状況に詳 いCSチームのリーダーに対 てヒアリングを行って い！←イマココ
40. Copyright levii Inc. All rights reserved. 状況設定資料（トークスクリプト例：ドメインエキスパート向 ） • コンテキストモデル（どんなステークホルダー？） ◦ 登場人物と ては、顧客、CS、要望管理システム、 ありま ◦ 顧客は要望管理システムに対 て要望を作成 ま ◦ CSは要望管理システムの中の要望を更新 ま ◦ 開発チームは要望管理システムの要望を確認 ま • 業務フロー（メインの動 ） ◦ 最初は、顧客 要望を思いついて、システムに登録 ると ろ らスタート ま ◦ CSは の要望を確認 て、対応方針を決めま ◦ 開発チームによる対応 必要なものは、CSチーム ら開発チームにSlackや口頭で対応を 願い ていま ◦ 開発チームによる対応 終わっ ら、CSチーム ら顧客に対 て修正終わっ とを連絡 ま ◦ 顧客に連絡 るのは、要望管理システムの要望にコメント機能 あるので れを使っていま ◦ 修正完了の連絡と同時に、要望のステータスを対応完了に変更 ていま ◦ まで 、 っ りと全体の流れで • 業務フロー（メイン以外の動 ） ◦ CS 要望を確認 と に、対応方針を決める めの情報 不足 てい ら、コメント機能を使って追加ヒア リングを ていま ◦ 状況をヒアリング 結果、直近では対応 ない、と判断 る ともありま 。 の場合も顧客には めんな い連絡を ていま 。 ◦ 要望 登録 れ と には、要望管理システム らCS宛にメール通知 ありま 。自分の登録 要望にコメ ント 追加 れ と にもメール通知 れるので、 客 んとのコミュニケーションに使っていま 。
41. ワーク１：業務フローモデリング(25分)
42. Copyright levii Inc. All rights reserved. ワークのアウトプットイメージ
43. Copyright levii Inc. All rights reserved. ステークホルダーを明ら に る • やる と ◦ の業務の関係者=ステークホルダーを「黄色の付箋」に書 出 ◦ 連携先のシステムも一つのステークホルダー • 質問例 ◦ 登場人物は誰で ？ ◦ ほ に関係者はいま ん ？ ◦ 対象のシステムは何で ？ ユーザー システム CS 1分 らいで登場人物 明ら になっ ら次のステップへ→
44. Copyright levii Inc. All rights reserved. ステークホルダーの関係を理解 る • やる と ◦ ステークホルダーを左に貼って関係性をシートに書 出 • 質問例 ◦ AとBはどういう関係性で ？ システ ム ユーザ CS システムを使う 1分 らいで関係性 明ら になっ ら次のステップへ→
45. Copyright levii Inc. All rights reserved. 業務フローを書 準備を る • やる と ◦ ステークホルダーをもう一枚付箋に書 出 、右側にはる ユーザ CS システ ム 時間軸 業務フローを右側に （業務フローの登場人物を黄色付箋 でもう一枚記述） システ ム ユーザ CS システムを使う
46. Copyright levii Inc. All rights reserved. アクションを書 出 • やる と ◦ ステークホルダーの中の１人に着目 て、業務で行っている行 動（アクション）を「赤色の付箋」に書 出 ◦ 最初は、全体像をつ みや いように、抽象度高めのふんわり アクションのままでOK • 質問例 ◦ 何 トリガーで業務は始まりま ？ ◦ 業務の完了条件は何で ？ ◦ いまは誰 やってま ？ ◦ システムは何をやってま ？ ◦ 〜の後は、いつもooを るんで ？ 違うパターンはありま ？ 時間軸 ooする ooする 〜を判 断 〜を 決める ooする チーム内での認識 ある程度 ろっ ら次のステップへ→ ユーザ CS システ ム
47. Copyright levii Inc. All rights reserved. 決断・判断基準を明ら に る • やる と ◦ 「決める」「判断 る」のアクションに着目 、 の めに必 要な情報を掘り下 て「橙色の付箋」に書 出 ◦ 「決める」「判断 る」のを誰 行う （人orシステム）も確 認 て、メモ て ▪ システム化: 判断基準を細 確認 る！ ▪ 人 やる: 判断に必要な情報を細 確認 る • 質問例 ◦ 判断を るには、どういう 情報 必要で ？ ◦ 情報はど で手に入りま ？ チーム内での認識 ある程度 ろっ ら次のステップへ→ 時間 な れば のステップは省略 てOK 時間軸 ooする ooする 〜を 判断 〜を 決める ユーザ CS ・重点顧客 ・不具合か ・回避策 ・業務影響 ....
48. Copyright levii Inc. All rights reserved. ワークのアウトプットイメージ
49. ワーク２：概念モデルを書 出
50. Copyright levii Inc. All rights reserved. ワーク２の前に：概念モデルとドメインモデル • 業務フローモデルは作りや い ◦ 時系列に沿ってヒアリング る とで、スムーズに情報を引 出 る！ • 、業務フロー=手続 • 責務を持っ 構造(オブジェクト)への変換 必要 ◦ システムの設計手法と て「責務を分 る」方 メンテナンス 性 高 なる 「手続 指向」→「オブジェクト指向」
51. Copyright levii Inc. All rights reserved. ワークのアウトプットイメージ
52. Copyright levii Inc. All rights reserved. 概念を書 出 • やる と ◦ 業務フローモデルに出て 概念を「青色の付箋」に書 出 • ポイント ◦ 業務フローモデル中の「名詞」に着目 る ◦ 業務の中心にある概念 ら、隣接 る概念を探 てい 要望 ユーザー (顧客) CS 状態 ある程度の数の概念 でて ら次のステップへ→
53. Copyright levii Inc. All rights reserved. 概念の関係性を整理 る • やる と ◦ 概念の間の関係性を アクティビティ（作成 る・参照 る・更新 る・など）と、 多重度（一対多・多対多・など）の観点で整理 る • 質問例: アクティビティの観点 ◦ ユーザーは要望を作成で ま ？更新で ま ？ • 質問例: 多重度の観点 ◦ ユーザーは複数個の要望を作る とはで ま ？ ◦ ユーザー 削除 れ と に、 のユーザー 作成 要望は どうなりま ？
54. Copyright levii Inc. All rights reserved. 概念の関係性を整理 る 要望 ユーザー (顧客) CS 1 * 「要望」という概念は、 顧客に対 て複数個紐付 る と で る 作成する 更新する アクティビティ 多重度 ※マーカーの色で区別 る
55. Copyright levii Inc. All rights reserved. 概念の認識を揃える（詳細を知る） • やる と ◦ 概念の保持 ている情報や、値のバリエーションを 「緑色の付箋」に書 出 • 質問例 ◦ 状態は、具体的にはどういう値・分類 ありま ？ ◦ 要望にはどんな情報 設定で ま ？ • ポイント ◦ 業務フローと行 来 な ら 探 とよい（次ワーク参照） 要望 状態 新規 対応完了 内容
56. Copyright levii Inc. All rights reserved. 整合性チェック • やる と ◦ 業務フローモデルのアクションを、作成 概念モデル 満 ている 確認 る • 進め方 ◦ はナビゲーター ファシリテーションを引 取る ◦ 業務フローモデルを指差 確認 な ら概念モデルをチェック ◦ 疑問や発見 あれば に共有 る！
57. Copyright levii Inc. All rights reserved. ワークのアウトプットイメージ
58. ワーク３：振り返り
59. Copyright levii Inc. All rights reserved. ワーク３：振り返り • 各チームで今日のワークショップの振り返りを 願い ま ◦ 2分：各自で付箋に記入 ◦ 8分：チーム内で共有 良かったこと わかったこと 気付 分からなかった こと 困った事 運営の改善点 質問 その他
60. Copyright levii Inc. All rights reserved. 全体質疑
61. Copyright levii Inc. All rights reserved. 最後に DDD は設計の本質を捉える力を れる 実践 るのは難 い(あらゆる意味で) 手伝い て れる人求む！ @levii_inc
62. ワークショップの手引
63. Copyright levii Inc. All rights reserved. 準備物 • ポストイット付箋 強粘着ネオンカラー 50x50mm ◦ https://www.amazon.co.jp/dp/B0013N1TWG/ • 油性ペン マッキー極細 ◦ https://www.amazon.co.jp/dp/B003M6AICY/ • ホワイトボード、ど でもシート、模造紙、など ◦ https://www.amazon.co.jp/dp/B01GCDLFG6/ 登場人物 (ステーク ホルダー) 行動 (アクション) 判断・分岐 概念 プロパティ
64. Copyright levii Inc. All rights reserved. アジェンダ（時間配分の目安） • [10分] 自己紹介ワーク • [15分] システム設計とドメインモデルについて • [5分] ワークショップの進め方を説明 • [25分] ワークショップ１：業務フローモデリング • [10分] 休憩 • [25分] ワークショップ２：概念モデリング • [10分] ワークショップ３：振り返り • [10分] 補足説明、質疑
65. Copyright levii Inc. All rights reserved. ファシリテーターの心構え • 全体を俯瞰 てとらえる ◦ 抜 ・漏れは無い 、一歩引いて全体像を確認 る問い を 忘れ に • システム化 る対象の業務を、自分 自信を持って行え る らいに細 掘り下 る ◦ 対象ドメインのコアな部分は、具体的な業務の確認を繰り返 ◦ 好奇心を持って、実際に業務を行っ 状況を想像 な ら、 「 んなケースはどうなる？」を問い る • 表出化 暗黙知を形式知に整理 て認識を揃える ◦ 暗黙知を言葉に ても、言葉 では認識を揃えるのは難 い ◦ 言葉の持つ意味を確認 て、 れらの関係性を整理 る とで 「概念」と て共通認識を持つ と で る
66. Copyright levii Inc. All rights reserved. ドメインモデルを書 出 ワーク：暗黙知を構造化 る • 概念を表 言葉に着目 る ◦ 似 概念との違いを明確に。言葉のブレ ら概念の違いを明ら に。 • 構造化 れ 概念群で業務フローを実現で る 確認 る ◦ 業務、アクションは、何ら の入力 ら何 を出力 る行為。 の入 力と出力 表現 れている 確認 る ◦ 判断を行う めに必要な概念は揃っている ？ • 概念の作成・変更・削除などのライフサイクルを考える ◦ 業務と て変更可能なタイミングや、変更不可能なタイミングはある ？ ◦ 外部環境の変化によって変更 れる箇所はある ？ の変更はどのよ うに取り扱うべ ？
67. Copyright levii Inc. All rights reserved. ワーク１：業務フローモデリング編の進め方 • ま は関係図を１分で書 ◦ 登場人物（ステークホルダー）を洗い出 て、システムとの関 係性を っ り把握 るの 目的 ◦ １分 らいでサクッと書 ◦ ワーク１質問カードの上半分の☆マーク付質問 らスタート • 次に、業務フローモデルを書 ◦ 登場人物（ステークホルダー）をもう一枚書 写 て、右側に も配置 る ◦ 質問シート下半分の☆マーク付質問 らスタート
68. Copyright levii Inc. All rights reserved. ワーク1：業務フローモデリングの めの質問カード 登場人物(利用者) は誰で ？ 対象のシステムは 何で ？ の登場人物とシ ステムはどういう 関係性で ？ 他にシステムに関 わっている人はい ま ん ？ 何 トリガーで 業務 始まりま ？ 何を満 ば業務 は終わりま ？ のアクションは 具体的には何を るんで ？ のアクション （判断）を行う めに必要な情報は 何で ？ ワーク1：コンテキストモデル ワーク1：コンテキストモデル ワーク1：コンテキストモデル ワーク1：コンテキストモデル ワーク1：業務フローモデル ワーク1：業務フローモデル ワーク1：業務フローモデル ワーク1：業務フローモデル
69. Copyright levii Inc. All rights reserved. ワーク２：概念モデリング編の進め方 • 概念モデルを書 始める ◦ 業務フローモデルの中にある名詞を手 りに、概念モデルを 構築 る。ま は、右下の概念モデルを書 写 てみる。 ◦ 概念と概念の間の関係性を声に出 な ら確認 てい • 幾つ の概念を追加 ら（10分 らい話 ら）、 業務フローモデルとの整合性を確認 る ◦ 業務フローモデルを指差 確認 な ら、 の業務を概念モデル で実現で る チェック る ◦ 見落と あれば、双方のモデル を更新 な ら、チームの認識を 揃える
70. Copyright levii Inc. All rights reserved. ワーク2：概念モデリングの めの質問カード 顧客 要望を作成 る とはで ま ？ 顧客 要望を更新 る とはで ま ？ CS 要望を更新 る とはで ま ？ CS 要望を削除 る とはで ま ？ 要望に対 て複数 の状態 関連付 とはありま ？ 要望に対 てコメ ントはい つ関連 付 る と で ま ？ 顧客は要望に紐付 い xxx(状態, 優先 度, など)を見る と はで ま ？ ワーク2：概念モデル (アクティビティ) ワーク2：概念モデル (アクティビティ) ワーク2：概念モデル (アクティビティ) ワーク2：概念モデル (アクティビティ) ワーク2：概念モデル (多重度・依存) ワーク2：概念モデル (多重度・依存) ワーク2：概念モデル (アクティビティ) ワーク2：概念モデル