ぐるぐるDDD(ドメイン駆動設計）に参加してみました
•
14 likes•6,102 views
2014/03/15にDevLove関西で開催されました「ぐるぐるDDD/Scrum - ドメイン駆動設計。モデリングと実装のうずまきをまわしてみよう」のワークショップに参加したときの体験談です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ぐるぐるDDD(ドメイン駆動設計）に参加してみました
Similar to ぐるぐるDDD(ドメイン駆動設計）に参加してみました (20)
More from Takuya Kawabe
Recently uploaded
Recently uploaded (9)
ぐるぐるDDD(ドメイン駆動設計）に参加してみました
- 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
- 11. なぜ？Scrumなの？ 11
- 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
- 19. 群盲象を評す ● システム開発も同じで目に見えない物が対象。 ● ではどうやって、全員でシステムを認識するの？ ● みんなで集まって、触った（担当）個所のドメインモデ ルを作る ● 大切なのは、みんなでモデルを作る事。 ● プログラマーだけがモデル化しても意味が無い ● プログラマー視点の、偏ったモデルになる危険性があ る。 19
- 20. モデルの抽象度 20
- 22. 牛のベッシーの教訓 ● ベッシー 、牝牛、 家畜、 農場資産、 資産、 富 ● 右に行くほど、抽象度が高くなる。 ● 抽象度が高いほど、話が通じる人は増えるが、具体 性は減少していく。 ● 抽象度が低いほど、コンテキストが一致しないと意味 が通じない。（ベッシーが牛であることを知らないとい けない） 22
- 23. プログラムにおける抽象度 ● プログラムも同様に、必要以上に抽象度が高いモデ ルを使うと、ロジックコピペが蔓延することになる。 ● つまり、抽象度が高いほど良いということはない。 ● プロジェクトに役に立つか検証する必要がある。 （⇒確かめないと判らない） ● 抽象度が判らない場合は、まずは具象的な形で作業 を進めたほうが良い。 23
- 26. １イテレーション目 26
- 28. 次にストーリを考えてみる 28 1.[ユーザ]車でゲートにくる 2.[システム] 発券する 3.[ユーザ] 券を受け取る 4.[システム] ゲート開ける 5.[ユーザ] ゲートに券を入れ る 6.[システム] 金額を計算して、 表示する 7.[ユーザ] 金額を入れる 8.[システム] ゲートを開ける
- 29. ストーリをモデル化 29
- 30. ストーリをモデル化 30 ● 最初は、ユーザや車などのオブジェクトも考えていま したが、コアドメインには含まれないだろうと判断して 除外しました。 除外したクルマや ユーザなどの オブジェクト
- 31. いよいよプログラム実装 31 ● まずはストーリを成立させるテストを書く （例：チケットをゲートにいれてお金をいれるとゲートが 開く など） ● 次にテストがレッドになるように、プロダクトソースを書 く ● テストがグリーンになったら、次のストーリへ進んで良 い ● ATDDと同じ？
- 33. ふりかえり 33 ● すべてのストーリを実装できなかった。 ● プログラム実装に入るのが時間ギリギリだった。 （普段、無駄な設計するよりか、プログラムしたほうが マシだよねって思ってたのに…ぐぬぬ） ● プログラム実装に入ってから気づいた事が多かった ⇒ 料金計算がメンドクサイ ⇒ チケット無くしたらどうするの？ ⇒ チケットの紙が無くなったら、どうするの？ ⇒ 満車になったら、どうするの？ ● Scrum的に、リリースできるものが無いって・・・otz
- 34. 原田さんからヒント 34 ● 自分たちのモデルがコアドメインに注力できていたか 考えてみよう。 ● プログラム実装で気づきが多いということは、良いこと だが、モデルが大きくて不確定要素を多く含んでいる というサインでもある。 ● 全チームとも、モデルが大きかった。 ● コンテキストマップを描いて、別領域と考えてもいいも のがあるのでは？ （料金計算や、チケット読み取り処理など） ● みんながイメージしている駐車場を、もっと単純化して みよう。
- 39. プログラム実装で問題発生 ● 単純に駐車場Noを持たせれば、簡単に複数台駐車 に対応できると思っていたが、意外と難航。 ● テストに複数条件を書く必要が出てきて、テストケース が急激に増加。。。 ● プロダクトソースに手を加える箇所が多かった。 39
- 42. 原田さんからの再ヒント１ 42 ● イテレーション2回目以降で回転が早かったのには、 理由がある ⇒ モデルを小さくした ⇒ ユビキタス言語使うことで、話がスムーズになった ● 小さくする技術は、捨てる技術でもあるよ。 ● コアドメインは、状況・目的が変わるともちろん変わ る。使えるドメインを探すようにしよう。 ● プログラムが複雑化したときは、モデル再検討が結局 一番の近道である。
- 43. 原田さんからの再ヒント２ 43 ● DDDで嵌る問題として、モデルを作る事を目的として しまう事がある。 ● それをScrumを使う事で、一定間隔でリリースすると いう制約で補う事ができる。 ● また短いサイクルでフィードバックを得ることで、軽量 なモデルを作る事が出来る。 ● しかし、DDDは難しいので常に練習して素振りするこ とが大切である。
- 44. いろいろQ＆A 44
- 48. いろいろQ&A 質問： モデルのリファクタリングに指標はありますか？ 回答： ● TDDと同じで、モデルをリファクタリングしても、TDD はグリーンのままとなる。 ● リファクタリング内容によっては、テストも手直しする 必要があります ● しかし、モデルのリファクタリングとテスト手直しは同 時にしてはならない。 ● このあたりのやり方に慣れるには、多少試行錯誤が 必要。 48
- 49. 興味深かった話 49
- 50. プロジェクトを小さく回す ● 出来るチームは、小さいプロジェクトを小さく回 せる。 ● これができないチームに大きいプロジェクトは任 せられない。 ● つまり、小さく回すことが出来ず、無駄に大きくし てしまう。 50
- 55. 自分のふりかえり 55
- 57. 自分のふりかえり ● 今回のワークショップとても勉強になったので、 是非またワークショップに参加してみたい。 ● でも、DDDのワークショップはなかなか見かけ られない状況。 ● DDDワークショップに興味を持った方は、 twitter： @kawakawa までご連絡下さい。 自身も初心者ながら、どのような形でワーク ショップが出来るのか、考えて行きたいです。 57