DDD/Scrumワークショップ · ドメイン駆動設計(ddd)はどうやる？...

DDD/Scrumワークショップモデリングと実装のうずまきをまわそう

原田騎郎 株式会社アトラクタ

1

UMTPセミナー 2017/2/13

原田 騎郎Kiro HARADA

アジャイルコーチ ドメインモデラー SCMコンサルタント

Twitter: @haradakiro

認定スクラムプロフェッショナル 株式会社アトラクタ　代表取締役

2

時間割(いまのところの見積)時間 内容14:05 ～ 14:45 ぐるぐる Scrum/DDD って何？14:50 ～ 15:50 ワークショップ１周目 15:40 ～ 15:50 　　１周目ふりかえり15:50 ～ 16:50 ワークショップ２周目 16:35 ～ 16:50 　　２周目ふりかえり16:50 ～ 17:00 講評/Scrum/DDDのこれから/ Q&A

3

アジェンダ

DDD って何？ Scrumって何？

DDD と Scrum の似ているところ？

両方のフィードバックサイクル

4

アジェンダ

で、どうやるの ▪プロダクトバックログとモデリング ▪スプリントプランニングとモデリング ▪バックログリファインメントとモデリング

▪コードレビューとモデリング ▪モデルのリファクタリング

5

アジェンダ

モデルをテストする ▪シナリオで確かめる ▪コードで確かめる。 ▪ ドメインモデルを TDD する

6

DDD実践してますか？

7

DDDをやらない理由？

難しいから、もうちょっと勉強してから

小さいシステムにはいらないでしょ

やったほうがよさそうだと思っているんだけれど。

8

実践書も出た

9

Scrumやれてますか？

10

Scrumをやらない理由

「どうせ、Scrum はやるもんじゃない！」って言うでしょ。

やってみたら問題ばっかりでてくるし。

「いきあたりばったりやっているだけじゃないの？」と突っ込まれるし。

11

どうやったらDDD & Scrumをうまくやれる？

使える？12

群盲撫象之図

13

群盲撫象之図

14

ドメイン駆動設計(DDD)とは

ソフトウェアプロジェクトで、まず注意を払うべきなのは、ドメインとドメインロジックである。

複雑なドメインの設計はモデルに基づくべきである。

15

ドメイン駆動設計(DDD)はどうやる？

コアドメインに集中する

ドメインの実務家とソフトウェアの実務家による創造的な共同作業によって、モデルと探求する

明確に境界づけられたコンテキストの中で、ユビキタス言語により会話する

16

モデル探索のうずまき

モデルを新しいシナリオで揺さぶる

シナリオ

モデルモデルを提示状態ウォークスルー解決策ウォークスルー言語の探求間違う

ストーリーを語る肉付けする難しいところに再フォーカスコアドメインに再フォーカス

コードによる探査シナリオを“テスト”としてコードする厳密さを加える言語を洗練する解決策を探求間違う

収穫＆文書化　参照シナリオ　まともなモデルの一部　ほとんどのアイデアは書かない

17

18

ストーリーを語る肉付けする難しいところに再フォーカスコアドメインに再フォーカス

収穫＆文書化　参照シナリオ　まともなモデルの一部　ほとんどのアイデアは書かない

シナリオを“テスト”としてコードする言語を洗練する厳密さを加える安価なプロトタイプシナリオをスクリプトにするやってみて、間違ったらコードを捨てる

モデルを提示状態ウォークスルー言語の探求厳密さを加える間違う

モデル探索のうずまき

いつでも複数のモデルがある

正しいモデルを探求する▪そもそも「唯一正しい」モデルなどない

より有用なモデルを探し続ける

19

地球のモデル？

Scrum の概要

複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

▪ 軽量▪ 理解が容易▪ 習得は困難

26

Scrum の概要

アジャイルなソフトウェア開発手法

そもそも、やり方(Methodology)ではない。やりかたの枠組み(Framework)にすぎない。

実際のやり方は、Scrumは指定しない。

よりよいやり方を探求し続ける27

28

29

Scrum のフィードバックサイクル

プロダクトバックログスプリントバックログ

バックログリファインメント

スプリントレビューふりかえり

出荷可能な増分30

クネビンフレームワーク

31http://cognitive-edge.com/

Cynefin Framework

32By Snowded - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=33783436

簡単に見えても、、、

33

複雑系で生き残る仕組み

境界

フィードバック

リズム

34

Sprint Zero

プロダクトビジョン

ユーザーストーリー▪ユースケースシナリオ

モデル

▪モデルとシナリオのうずまきをまわす35

プロダクトバックログ

ストーリーの順位付けをする

モデルを書いてみる▪ (モデルは常に複数ある)

▪モデルはストーリーを記述できるか？▪ モデルは役に立つか？

▪モデルをストーリーが十分説明できるか。▪ 足りていないストーリーはないか？

36

実装して確かめる

難しいモデルは実装して確かめる▪ドメインモデルのみ▪ 永続化層 / UI はとりあえず考えなくてよい

▪ 複数のモデルを確かめる▪ 記述力▪ 実装のしやすさ▪ テストのしやすさ▪ 拡張のしやすさ

37

スプリントより短い フィードバックサイクル

「検査と適応によって、間違っても、それから学べば良い」

けれど

わかる間違いには、気づきたい。２週間は短い。それ以上、短くするときつい。

38

モデルをどこに書く

ホワイトボード▪関心ごとのある部分だけホワイトボードに

適宜清書してリポジトリに▪ astah* 使ってます

39

コードレビュー

ドメイン以外にビジネスロジッックが埋もれていないか？

▪ドメインモデルに書いたテストを、そのまま使えるか？

▪実装しにくいところはどこか？▪ ドメインの使い方を間違えやすいところはどこか

40

新たなバックログが来た

バックログを見積もる

▪モデルの変更が不要

▪モデルの拡張が必要

▪モデルの変更が必要

41

複数のモデルを試す

スプリント期間を短くするだけでは成功は難しい。

単一のスプリント内で複数のオプションを試す。

モデルを利用した並行開発

42

サイクルの中で拡張の方向が見える

パターン指向リファクタリング

次のバックログが見えないうちにリファクタリングするのはアンチパターン

▪リファクタリングのためのリファクタリングは悪

43

モデルも必要に応じて拡張／変更

バックログが Ready になる前に実装モデルを拡張するな

▪概念モデル、仕様モデルをシナリオでテストしてから。

リファレンスモデル、パターンの適用を検討する

44

モデルの汎用性と抽象度

富資産農業資産家畜牝牛ベッシー

45S.I.Hayakawa “Language in Thoughts and Action” 1939

リファレンスモデルって

リファレンスモデルは抽象度が高く、再利用性が高い。▪時間をかけて確かめられている。

けれど

プロジェクトに役に立つかは、確かめないとわからない。

46

小規模プロジェクトこそ DDD + Scrum を

小規模プロジェクトは、要件変更に弱い▪ 使えるリソース、期間が限られている

小規模プロジェクトの範囲を DDD によるモデルで定義する。▪ モデルの拡張範囲を合意する▪ モデルの変更をともなうバックログは混入しない

47

パタンランゲージ

パターンランゲージとしての Scrum

パターンランゲージとしてのDomain Driven Design

48

DDD Patterns

49

Scrum Pattern Language

50

http://jeffsutherland.org/scrum/scrum_plop.pdf

Organizational Patterns

51Coplien, James and Neil Harrison. Patterns of Agile Software Development. Addison-Wesley, ©2004.

Scrum と DDDありがちなハマりどころ 対応策モデリング地獄(DDD)• モデルを作ることを目標にしてしまう

• いつまでたってもモデルが完成しない

スプリント(Scrum)• 出荷可能な製品を２週間ごとに！• モデリングも含めて使えるフィーチャーを２週間で作らなければならない。

全体を見ないで開発(Scrum)• システムの全体像を考えない• 全体計画を立てない

ユビキタス言語(DDD)• みなが使える共通言語をつくる• 共通言語による全体理解を促進• 全体計画のガイドとしてのモデル

52

まとめ

DDDとScrumは、うまく組合せられる▪ DDDもScrumも変える必要がない▪お互いのメリットをうまく使える

短いサイクルを軽量にまわすのが大事

まずは、小さく始めてみましょう。

53

ぐるぐる実践編

５人程度のグループを作ってください

グループ作業がしやすい用に、机、椅子は適宜並べ替えてください。

４５分後に、簡単に成果の発表をしていただきます。

54

今回のお題は？

駐車場55

駐車場？

56

57

58

59

60

61

62

63

64

駐車場の種類:

空き地月極め駐車場時間貸しコインパーキング店舗に付属店舗と提携

65

今回作るシステムは、

無人有料駐車場(時間貸し)の管理システム

66

どんな機能が必要？

シナリオを書いてみる

基本シナリオ？派生シナリオ？

どう拡張される？

67

どんなモデルになる？

シナリオを記述できるモデルを書いてみる

そのモデルに足りないシナリオはない？

68

モデル探索のうずまき

モデルを新しいシナリオで揺さぶる

シナリオ

モデルモデルを提示状態ウォークスルー解決策ウォークスルー言語の探求間違う

ストーリーを語る肉付けする難しいところに再フォーカスコアドメインに再フォーカス

コードによる探査シナリオを“テスト”としてコードする厳密さを加える言語を洗練する解決策を探求間違う

収穫＆文書化　参照シナリオ　まともなモデルの一部　ほとんどのアイデアは書かない

69

70

ストーリーを語る肉付けする難しいところに再フォーカスコアドメインに再フォーカス

収穫＆文書化　参照シナリオ　まともなモデルの一部　ほとんどのアイデアは書かない

シナリオを“テスト”としてコードする言語を洗練する厳密さを加える安価なプロトタイプシナリオをスクリプトにするやってみて、間違ったらコードを捨てる

モデルを提示状態ウォークスルー言語の探求厳密さを加える間違う

モデル探索のうずまき

コアドメインを実装してみよう

永続化、UI はいらない

モデルがそのまま動けるかどうか？

71

作ってほしいもの

プロダクトバックログ▪優先順位のついたシナリオのリスト

ドメインモデル▪ UML のクラス図など▪ドメインの理解を助けるものなら何でも

コアドメインのサンプル実装▪コアドメインの受入れテストがあるといいな

72

イテレーション１開始

４５分しかありません。

時間の使いかたを計画しましょう。

73

イテレーション１発表

成果を説明してみましょう。

74

イテレーション１ふりかえり

びっくりしたこと、気づいたこと

学んだこと

次にやってみること

75

イテレーション２に向けて

76

どんなシナリオがある？

週末料金？夜間料金？煩雑期と閑散期

店舗利用による無料範囲会員割引

誤入場をどうしよう？駐車券なくしちゃったら？

77

どうシステムを分割する？

駐車場の種類が変わると、変える必要のある部分は？▪車止め式▪ゲート式▪出場時にナンバーを認識する？

78

モデルを眺める

駐車料金が変わると、どこが変わる？

週末料金とかは？

車止め vs. 入退場ゲート

79

80

こんな駐車場もあるららぽーと甲子園駐車場

81http://www.lalaport-koshien.com/access/index.html#05

コアドメインはどこ？

82

コンテキストマップ？

83

イテレーション２発表

成果を説明してみましょう。

84

イテレーション２ふりかえり

びっくりしたこと、気づいたこと

学んだこと

次にやってみること

85

全体ふりかえり

DDD / Scrum を実際の業務で使ってみるには？

▪グループディスカッション

86

課題２

レンタサイクルの管理システム

87

シナリオ

レンタサイクル一台だけ

故障状態の管理(パンクなど)

複数台(複数サイズ-大人用、子供用)

電動アシスト付き(充電状態の管理)

88

サブシナリオ

延滞の扱い

予約の扱い

▪予約済みのレンタサイクルが故障したら

89

さらにシナリオ

複数拠点▪拠点間の乗り捨て ▪ある拠点にレンタサイクルが集まってしまったら？

90