2014/03/15にDevLove関西で開催されました「ぐるぐるDDD/Scrum - ドメイン駆動設計。モデリングと実装のうずまきをまわしてみよう」のワークショップに参加したときの体験談です。

1. ぐるぐるDDDに参加してみました！
1

2. お断り <(_ _)>ﾍﾟｺﾘ
当資料は、DevLove関西で行われたワークショップ
『ぐるぐるDDD/Scrum – ドメイン駆動設計。
モデリングと実装のうずまきをまわしてみよう』
の体験記となります。
ワークショップ未経験者にはネタバレ箇所をボカシつつも、
ワークショップの醍醐味は失わないように書いたつもりです。
もしワークショップの面白さが伝わらなかったのならば、私の
責任です。
ワークショップは本当に面白く、目から鱗が出るほど、
素晴らしい経験をする事が出来ました。
2

3. 自己紹介
3
● かわべ たくや
● Twitter : @kawakawa
● 大阪在住
● C#をメインにお仕事しています
● DDD猛烈勉強中！

4. ワークショップ講師紹介
原田騎郎氏
・ 株式会社アトラクタ代表
・ Twitter : @haradakiro
・ アジャイルコーチ
・ ドメインモデラー
・ SCM(サプライチェーンマネジメント)コンサルタント
4

5. ワークショップ講師紹介
原田騎郎氏
・ 株式会社アトラクタ代表
・ Twitter : @haradakiro
・ アジャイルコーチ
・ ドメインモデラー
・ SCM(サプライチェーンマネジメント)コンサルタント
DDD＆Scrumのワークショップが少ないのは、
両方を同時にコーチング出来る人が少ないからではな
いでしょうか。
そういう意味でも、凄い人です。
5

6. DDDで大切な事
6

7. DDDで大切な事
『ドメイン』と『ドメインロジック』に注意しよう
ドメイン＝問題の領域や、知識範囲など。
ドメインロジック＝ドメインを実現する箇所や方法。
7

8. DDDで大切な事
難しい・複雑なドメイン設計は、
モデルに基づくべきである。
・難しいモデルは実装してみて判る事が多い。
・そのため、プログラム実装⇒フィードバック⇒
モデル再構築の流れ（リズム）が大切になる。
8

9. DDDで大切な事
モデルは複数存在している。
Theモデルなんてものは存在しない。
正しいモデルを探すのではなく、
“使えるモデル”を探すのがDDDである。
9

10. DDDで大切な事
ツールに頼らない
● ホワイトボードなどに殴り書きでもいいので、全員がモ
デルを書けるようになることが大切
● きれいなモデル図は必要ない。殴り書きでよい。
●
綺麗なモデル図が必要な場合は、モデルが落ち着い
てから、ツールで清書してリポジトリに保管。
10

11. なぜ？Scrumなの？
11

12. なぜ？Scrumなの？
DDD(ドメイン駆動設計)は設計手法である
● DDDは、ウォーターフォールやアジャイルなど、いろ
いろな開発フレームワークで利用出来る。
● 逆に言うとDDDは、開発を進めるリズムについては規
定していないことになる。
12

13. なぜ？Scrumなの？
DDD(ドメイン駆動設計)は設計手法である
● DDDは、ウォーターフォールやアジャイルなど、いろ
いろな開発フレームワークで利用出来る。
● 逆に言うとDDDは、開発を進めるリズムについては規
定していないことになる。
● その為、当ワークショップは、Scrumでイテレーション
を回して、フィードバックでモデルがどのように変化し
ていくのか体験するのが目的の1つとなります。
13

14. Model Exploration Whirlpool
14
• 原田さん資料より http://www.slideshare.net/kiroh/scrum-andddd-tdc2013distss

15. Model Exploration Whirlpool
15
• 原田さん資料より http://www.slideshare.net/kiroh/scrum-andddd-tdc2013distss
シナリオとモデルを回して洗練させつつ、
プログラム実装の大きいループでも、
フィードバック得て、洗練させる。

16. 閑話休題
16

17. 群盲象を評す
17
• http://upload.wikimedia.org/wikipedia/commons/4/45/Blind_monks_examining_a
n_elephant.jpg

18. 群盲象を評す
●
群盲象を評す（ぐんもうぞうをひょうす）
●
数人の盲人が象の一部だけを触って感想を語り合
う、というインド発祥の寓話。
● 盲人達は、それぞれ象の鼻や牙など別々の一部分だ
けを触り、その感想について語り合う。しかし触った部
位により感想が異なり、それぞれが自分が正しいと主
張して対立が深まる。しかし何らかの理由でそれが同
じ物の別の部分であると気づき、対立が解消する、と
いうもの。
● 以上、ウィキペディア より抜粋。
18

19. 群盲象を評す
●
システム開発も同じで目に見えない物が対象。
● ではどうやって、全員でシステムを認識するの？
● みんなで集まって、触った（担当）個所のドメインモデ
ルを作る
●
大切なのは、みんなでモデルを作る事。
●
プログラマーだけがモデル化しても意味が無い
● プログラマー視点の、偏ったモデルになる危険性があ
る。
19

20. モデルの抽象度
20

21. 牛のベッシー
21
• http://homepage3.nifty.com/manabizz/Chushou.pdf

22. 牛のベッシーの教訓
●
ベッシー 、牝牛、 家畜、 農場資産、 資産、 富
●
右に行くほど、抽象度が高くなる。
● 抽象度が高いほど、話が通じる人は増えるが、具体
性は減少していく。
● 抽象度が低いほど、コンテキストが一致しないと意味
が通じない。（ベッシーが牛であることを知らないとい
けない）
22

23. プログラムにおける抽象度
●
プログラムも同様に、必要以上に抽象度が高いモデ
ルを使うと、ロジックコピペが蔓延することになる。
● つまり、抽象度が高いほど良いということはない。
● プロジェクトに役に立つか検証する必要がある。
（⇒確かめないと判らない）
● 抽象度が判らない場合は、まずは具象的な形で作業
を進めたほうが良い。
23

24. いよいよ本題
DDD/Scrumワークショップ
24

25. お題は『駐車場』
●
無人有料駐車場（時間貸し）の管理システムを構築。
●
チームに分かれて、作業を行います。
● 1イテレーション50分で複数回まわします。
● １つのイテレーション内でソース実装まで行いリリース
できる状態にします。
25

26. １イテレーション目
26

27. まずはイメージの共有
●
ゲート式の駐車場をイメージ
●
入り口用と出口用ゲートは別れている
27

28. 次にストーリを考えてみる
28
1.[ユーザ]車でゲートにくる
2.[システム] 発券する
3.[ユーザ] 券を受け取る
4.[システム] ゲート開ける
5.[ユーザ] ゲートに券を入れ
る
6.[システム] 金額を計算して、
表示する
7.[ユーザ] 金額を入れる
8.[システム] ゲートを開ける

29. ストーリをモデル化
29

30. ストーリをモデル化
30
●
最初は、ユーザや車などのオブジェクトも考えていま
したが、コアドメインには含まれないだろうと判断して
除外しました。
除外したクルマや
ユーザなどの
オブジェクト

31. いよいよプログラム実装
31
●
まずはストーリを成立させるテストを書く
（例：チケットをゲートにいれてお金をいれるとゲートが
開く など）
● 次にテストがレッドになるように、プロダクトソースを書
く
● テストがグリーンになったら、次のストーリへ進んで良
い
● ATDDと同じ？

32. １イテレーション目終了
＆ふりかえり
32

33. ふりかえり
33
●
すべてのストーリを実装できなかった。
●
プログラム実装に入るのが時間ギリギリだった。
（普段、無駄な設計するよりか、プログラムしたほうが
マシだよねって思ってたのに…ぐぬぬ）
● プログラム実装に入ってから気づいた事が多かった
⇒ 料金計算がメンドクサイ
⇒ チケット無くしたらどうするの？
⇒ チケットの紙が無くなったら、どうするの？
⇒ 満車になったら、どうするの？
● Scrum的に、リリースできるものが無いって・・・otz

34. 原田さんからヒント
34
●
自分たちのモデルがコアドメインに注力できていたか
考えてみよう。
● プログラム実装で気づきが多いということは、良いこと
だが、モデルが大きくて不確定要素を多く含んでいる
というサインでもある。
● 全チームとも、モデルが大きかった。
● コンテキストマップを描いて、別領域と考えてもいいも
のがあるのでは？
（料金計算や、チケット読み取り処理など）
● みんながイメージしている駐車場を、もっと単純化して
みよう。

35. ２イテレーション目
＆
３イテレーション目
35

36. 再度イメージを練り直し
●
単純に１台だけの車が入って、出るだけの駐車場
●
料金は時間に関係なく、一律１０００円と設定
● モデルを単純化
36

37. 再度プログラム実装
●
モデルの単純化は、テストの単純化につながった。
（お金を払う⇒出庫OK、
お金を払わなない⇒出庫NG)
● この時、お金も１０００円という具体的な金額より、［お
金］という抽象的なものでOKという事が分かった。
⇒モデルにフィードバック
37

38. モデルの拡張
●
３イテレーション目に入って、モデルの拡張に挑戦
（時間経過による料金計算、または複数台駐車）
● まずは複数台駐車に挑戦
38
駐車場所Noを持つ事で、
複数台駐車に対応

39. プログラム実装で問題発生
● 単純に駐車場Noを持たせれば、簡単に複数台駐車
に対応できると思っていたが、意外と難航。
● テストに複数条件を書く必要が出てきて、テストケース
が急激に増加。。。
● プロダクトソースに手を加える箇所が多かった。
39

40. ２・３イテレーション目終了
＆ふりかえり
40

41. ふりかえり
41
●
グリーンには出来なかったが、全ストーリをプログラム
実装することは出来た。
● プログラムが複雑化したとき、１回目より深いレベルで
モデル検討が出来た気がした。
● 複雑化したといっても、１回目にくらべたら、かなりシ
ンプルなプログラムになった。

42. 原田さんからの再ヒント１
42
● イテレーション2回目以降で回転が早かったのには、
理由がある
⇒ モデルを小さくした
⇒ ユビキタス言語使うことで、話がスムーズになった
●
小さくする技術は、捨てる技術でもあるよ。
●
コアドメインは、状況・目的が変わるともちろん変わ
る。使えるドメインを探すようにしよう。
● プログラムが複雑化したときは、モデル再検討が結局
一番の近道である。

43. 原田さんからの再ヒント２
43
● DDDで嵌る問題として、モデルを作る事を目的として
しまう事がある。
● それをScrumを使う事で、一定間隔でリリースすると
いう制約で補う事ができる。
● また短いサイクルでフィードバックを得ることで、軽量
なモデルを作る事が出来る。
● しかし、DDDは難しいので常に練習して素振りするこ
とが大切である。

44. いろいろQ＆A
44

45. いろいろQ&A
質問：
ロック式とゲート式駐車場のコアドメインは同じに
なるのですか？
回答：
それを考えるのがリファクタリンク。
答えを言うと、同じになりますよ。
（後でモデル図を用いて、同じになる事を実演）
45

46. いろいろQ&A
質問：
コアドメインとサブドメインはどうやって決めるの
ですか？
回答：
切り分けられるのならば、コンテキストマップを使う。
判らないのなら、実装して試してみよう。
話し合っても判らないのなら、永遠に判らない。
まずは実装だ。
46

47. いろいろQ&A
質問：
モデル検討からプログラム実装へ移るタイミング
は？
回答：
やれば判るよ。
今日のワークショップで何となく判ったでしょ。
47

48. いろいろQ&A
質問：
モデルのリファクタリングに指標はありますか？
回答：
● TDDと同じで、モデルをリファクタリングしても、TDD
はグリーンのままとなる。
● リファクタリング内容によっては、テストも手直しする
必要があります
● しかし、モデルのリファクタリングとテスト手直しは同
時にしてはならない。
● このあたりのやり方に慣れるには、多少試行錯誤が
必要。
48

49. 興味深かった話
49

50. プロジェクトを小さく回す
● 出来るチームは、小さいプロジェクトを小さく回
せる。
● これができないチームに大きいプロジェクトは任
せられない。
● つまり、小さく回すことが出来ず、無駄に大きくし
てしまう。
50

51. 常にグリーンになるテストの対処法
● １年以上、グリーンになるテストはUnitテストか
ら外しても良い。
● 開発中のテスト(特にTDD)は、フィードバックの
スピードが重要。
●
つまりスコープを小さくするのが大切。
●
常にグリーンになるテストがいるとフィードバック
が遅くなる危険がある。
●
重要なテストならば、リリース前にだけテスト確
認すれば良い
51

52. DDDの練習課題
DDDやプログラミングの練習には、ボブおじさん
の「Bowling Game Kata」がオススメ。
http://butunclebob.com/ArticleS.UncleBob.Th
eBowlingGameKata
52

53. デザインパターンについて
デザインパターンなどのパターンは、形にはまる
と強力だが、その本質を理解しないで利用すると
応用が利かない、歪んだ形となる事が多い。
パターンの本質を理解しないのなら、使わない方
がマシ。
53

54. インスタンス生成のコスト
クラスからインスタンスを生成する際、容易に
newしていませんか？
駐車場クラスを安易にｎｅｗしてませんでしたか？
現実はそんなに簡単に、駐車場は作られませ
ん。それなりにコストが必要です。
ＤＤＤ本にも、エンジンを作る工場の話がありま
すが、役割（責務）だけでなく、生成コストも視野
に入れて、モデルを考えてみると良いですよ。
54

55. 自分のふりかえり
55

56. 自分のふりかえり
● DDDのリファクタリンクとはどのようなものか、
体験できたのは本当に貴重な経験となった。
●
コアドメインを探求する抽象化（または単純化）
の感覚がまだ見えてこない。
なんかセンスが必要な気がしてきた・・・うーむ。
●
プログラムからのフィードバック重要。卓上のモ
デル化だけでは見えてこない事が多い。
56

57. 自分のふりかえり
● 今回のワークショップとても勉強になったので、
是非またワークショップに参加してみたい。
● でも、DDDのワークショップはなかなか見かけ
られない状況。
● DDDワークショップに興味を持った方は、
twitter： @kawakawa までご連絡下さい。
自身も初心者ながら、どのような形でワーク
ショップが出来るのか、考えて行きたいです。
57