Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ぐるぐるDDD(ドメイン駆動設計)に参加してみました

4,711 views

Published on

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

Published in: Technology
  • Be the first to comment

ぐるぐるDDD(ドメイン駆動設計)に参加してみました

  1. 1. ぐるぐるDDDに参加してみました! 1
  2. 2. お断り <(_ _)>ペコリ  当資料は、DevLove関西で行われたワークショップ 『ぐるぐるDDD/Scrum – ドメイン駆動設計。 モデリングと実装のうずまきをまわしてみよう』 の体験記となります。  ワークショップ未経験者にはネタバレ箇所をボカシつつも、 ワークショップの醍醐味は失わないように書いたつもりです。  もしワークショップの面白さが伝わらなかったのならば、私の 責任です。 ワークショップは本当に面白く、目から鱗が出るほど、 素晴らしい経験をする事が出来ました。 2
  3. 3. 自己紹介 3 ● かわべ たくや ● Twitter : @kawakawa ● 大阪在住 ● C#をメインにお仕事しています ● DDD猛烈勉強中!
  4. 4. ワークショップ講師紹介 原田騎郎氏  ・ 株式会社アトラクタ代表  ・ Twitter : @haradakiro  ・ アジャイルコーチ  ・ ドメインモデラー  ・ SCM(サプライチェーンマネジメント)コンサルタント 4
  5. 5. ワークショップ講師紹介 原田騎郎氏  ・ 株式会社アトラクタ代表  ・ Twitter : @haradakiro  ・ アジャイルコーチ  ・ ドメインモデラー  ・ SCM(サプライチェーンマネジメント)コンサルタント DDD&Scrumのワークショップが少ないのは、 両方を同時にコーチング出来る人が少ないからではな いでしょうか。 そういう意味でも、凄い人です。 5
  6. 6. DDDで大切な事 6
  7. 7. DDDで大切な事 『ドメイン』と『ドメインロジック』に注意しよう ドメイン=問題の領域や、知識範囲など。 ドメインロジック=ドメインを実現する箇所や方法。 7
  8. 8. DDDで大切な事 難しい・複雑なドメイン設計は、 モデルに基づくべきである。 ・難しいモデルは実装してみて判る事が多い。 ・そのため、プログラム実装⇒フィードバック⇒  モデル再構築の流れ(リズム)が大切になる。 8
  9. 9. DDDで大切な事 モデルは複数存在している。 Theモデルなんてものは存在しない。 正しいモデルを探すのではなく、 “使えるモデル”を探すのがDDDである。 9
  10. 10. DDDで大切な事 ツールに頼らない ● ホワイトボードなどに殴り書きでもいいので、全員がモ デルを書けるようになることが大切 ● きれいなモデル図は必要ない。殴り書きでよい。 ● 綺麗なモデル図が必要な場合は、モデルが落ち着い てから、ツールで清書してリポジトリに保管。 10
  11. 11. なぜ?Scrumなの? 11
  12. 12. なぜ?Scrumなの? DDD(ドメイン駆動設計)は設計手法である ● DDDは、ウォーターフォールやアジャイルなど、いろ いろな開発フレームワークで利用出来る。 ● 逆に言うとDDDは、開発を進めるリズムについては規 定していないことになる。 12
  13. 13. なぜ?Scrumなの? DDD(ドメイン駆動設計)は設計手法である ● DDDは、ウォーターフォールやアジャイルなど、いろ いろな開発フレームワークで利用出来る。 ● 逆に言うとDDDは、開発を進めるリズムについては規 定していないことになる。 ● その為、当ワークショップは、Scrumでイテレーション を回して、フィードバックでモデルがどのように変化し ていくのか体験するのが目的の1つとなります。 13
  14. 14. Model Exploration Whirlpool 14 • 原田さん資料より http://www.slideshare.net/kiroh/scrum-andddd-tdc2013distss
  15. 15. Model Exploration Whirlpool 15 • 原田さん資料より http://www.slideshare.net/kiroh/scrum-andddd-tdc2013distss シナリオとモデルを回して洗練させつつ、 プログラム実装の大きいループでも、 フィードバック得て、洗練させる。
  16. 16. 閑話休題 16
  17. 17. 群盲象を評す 17 • http://upload.wikimedia.org/wikipedia/commons/4/45/Blind_monks_examining_a n_elephant.jpg
  18. 18. 群盲象を評す ● 群盲象を評す(ぐんもうぞうをひょうす) ● 数人の盲人が象の一部だけを触って感想を語り合 う、というインド発祥の寓話。 ● 盲人達は、それぞれ象の鼻や牙など別々の一部分だ けを触り、その感想について語り合う。しかし触った部 位により感想が異なり、それぞれが自分が正しいと主 張して対立が深まる。しかし何らかの理由でそれが同 じ物の別の部分であると気づき、対立が解消する、と いうもの。 ● 以上、ウィキペディア より抜粋。 18
  19. 19. 群盲象を評す ● システム開発も同じで目に見えない物が対象。 ● ではどうやって、全員でシステムを認識するの? ● みんなで集まって、触った(担当)個所のドメインモデ ルを作る ● 大切なのは、みんなでモデルを作る事。 ● プログラマーだけがモデル化しても意味が無い ● プログラマー視点の、偏ったモデルになる危険性があ る。 19
  20. 20. モデルの抽象度 20
  21. 21. 牛のベッシー 21 • http://homepage3.nifty.com/manabizz/Chushou.pdf
  22. 22. 牛のベッシーの教訓 ● ベッシー 、牝牛、 家畜、 農場資産、 資産、 富 ● 右に行くほど、抽象度が高くなる。 ● 抽象度が高いほど、話が通じる人は増えるが、具体 性は減少していく。 ● 抽象度が低いほど、コンテキストが一致しないと意味 が通じない。(ベッシーが牛であることを知らないとい けない) 22
  23. 23. プログラムにおける抽象度 ● プログラムも同様に、必要以上に抽象度が高いモデ ルを使うと、ロジックコピペが蔓延することになる。 ● つまり、抽象度が高いほど良いということはない。 ● プロジェクトに役に立つか検証する必要がある。 (⇒確かめないと判らない) ● 抽象度が判らない場合は、まずは具象的な形で作業 を進めたほうが良い。 23
  24. 24. いよいよ本題 DDD/Scrumワークショップ 24
  25. 25. お題は『駐車場』 ● 無人有料駐車場(時間貸し)の管理システムを構築。 ● チームに分かれて、作業を行います。 ● 1イテレーション50分で複数回まわします。 ● 1つのイテレーション内でソース実装まで行いリリース できる状態にします。 25
  26. 26. 1イテレーション目 26
  27. 27. まずはイメージの共有 ● ゲート式の駐車場をイメージ ● 入り口用と出口用ゲートは別れている 27
  28. 28. 次にストーリを考えてみる 28 1.[ユーザ]車でゲートにくる 2.[システム] 発券する 3.[ユーザ] 券を受け取る 4.[システム] ゲート開ける 5.[ユーザ] ゲートに券を入れ る 6.[システム] 金額を計算して、 表示する 7.[ユーザ] 金額を入れる 8.[システム] ゲートを開ける
  29. 29. ストーリをモデル化 29
  30. 30. ストーリをモデル化 30 ● 最初は、ユーザや車などのオブジェクトも考えていま したが、コアドメインには含まれないだろうと判断して 除外しました。 除外したクルマや ユーザなどの オブジェクト
  31. 31. いよいよプログラム実装 31 ● まずはストーリを成立させるテストを書く (例:チケットをゲートにいれてお金をいれるとゲートが 開く など) ● 次にテストがレッドになるように、プロダクトソースを書 く ● テストがグリーンになったら、次のストーリへ進んで良 い ● ATDDと同じ?
  32. 32. 1イテレーション目終了 &ふりかえり 32
  33. 33. ふりかえり 33 ● すべてのストーリを実装できなかった。 ● プログラム実装に入るのが時間ギリギリだった。 (普段、無駄な設計するよりか、プログラムしたほうが マシだよねって思ってたのに…ぐぬぬ) ● プログラム実装に入ってから気づいた事が多かった  ⇒ 料金計算がメンドクサイ  ⇒ チケット無くしたらどうするの?  ⇒ チケットの紙が無くなったら、どうするの?  ⇒ 満車になったら、どうするの? ● Scrum的に、リリースできるものが無いって・・・otz
  34. 34. 原田さんからヒント 34 ● 自分たちのモデルがコアドメインに注力できていたか 考えてみよう。 ● プログラム実装で気づきが多いということは、良いこと だが、モデルが大きくて不確定要素を多く含んでいる というサインでもある。 ● 全チームとも、モデルが大きかった。 ● コンテキストマップを描いて、別領域と考えてもいいも のがあるのでは? (料金計算や、チケット読み取り処理など) ● みんながイメージしている駐車場を、もっと単純化して みよう。
  35. 35. 2イテレーション目 & 3イテレーション目 35
  36. 36. 再度イメージを練り直し ● 単純に1台だけの車が入って、出るだけの駐車場 ● 料金は時間に関係なく、一律1000円と設定 ● モデルを単純化 36
  37. 37. 再度プログラム実装 ● モデルの単純化は、テストの単純化につながった。 (お金を払う⇒出庫OK、  お金を払わなない⇒出庫NG) ● この時、お金も1000円という具体的な金額より、[お 金]という抽象的なものでOKという事が分かった。 ⇒モデルにフィードバック 37
  38. 38. モデルの拡張 ● 3イテレーション目に入って、モデルの拡張に挑戦  (時間経過による料金計算、または複数台駐車) ● まずは複数台駐車に挑戦 38 駐車場所Noを持つ事で、 複数台駐車に対応
  39. 39. プログラム実装で問題発生 ● 単純に駐車場Noを持たせれば、簡単に複数台駐車 に対応できると思っていたが、意外と難航。 ● テストに複数条件を書く必要が出てきて、テストケース が急激に増加。。。 ● プロダクトソースに手を加える箇所が多かった。 39
  40. 40. 2・3イテレーション目終了 &ふりかえり 40
  41. 41. ふりかえり 41 ● グリーンには出来なかったが、全ストーリをプログラム 実装することは出来た。 ● プログラムが複雑化したとき、1回目より深いレベルで モデル検討が出来た気がした。 ● 複雑化したといっても、1回目にくらべたら、かなりシ ンプルなプログラムになった。
  42. 42. 原田さんからの再ヒント1 42 ● イテレーション2回目以降で回転が早かったのには、 理由がある ⇒ モデルを小さくした ⇒ ユビキタス言語使うことで、話がスムーズになった ● 小さくする技術は、捨てる技術でもあるよ。 ● コアドメインは、状況・目的が変わるともちろん変わ る。使えるドメインを探すようにしよう。 ● プログラムが複雑化したときは、モデル再検討が結局 一番の近道である。
  43. 43. 原田さんからの再ヒント2 43 ● DDDで嵌る問題として、モデルを作る事を目的として しまう事がある。 ● それをScrumを使う事で、一定間隔でリリースすると いう制約で補う事ができる。 ● また短いサイクルでフィードバックを得ることで、軽量 なモデルを作る事が出来る。 ● しかし、DDDは難しいので常に練習して素振りするこ とが大切である。
  44. 44. いろいろQ&A 44
  45. 45. いろいろQ&A 質問: ロック式とゲート式駐車場のコアドメインは同じに なるのですか? 回答: それを考えるのがリファクタリンク。 答えを言うと、同じになりますよ。 (後でモデル図を用いて、同じになる事を実演) 45
  46. 46. いろいろQ&A 質問: コアドメインとサブドメインはどうやって決めるの ですか? 回答: 切り分けられるのならば、コンテキストマップを使う。 判らないのなら、実装して試してみよう。 話し合っても判らないのなら、永遠に判らない。 まずは実装だ。 46
  47. 47. いろいろQ&A 質問: モデル検討からプログラム実装へ移るタイミング は? 回答: やれば判るよ。 今日のワークショップで何となく判ったでしょ。 47
  48. 48. いろいろQ&A 質問: モデルのリファクタリングに指標はありますか? 回答: ● TDDと同じで、モデルをリファクタリングしても、TDD はグリーンのままとなる。 ● リファクタリング内容によっては、テストも手直しする 必要があります ● しかし、モデルのリファクタリングとテスト手直しは同 時にしてはならない。 ● このあたりのやり方に慣れるには、多少試行錯誤が 必要。 48
  49. 49. 興味深かった話 49
  50. 50. プロジェクトを小さく回す ● 出来るチームは、小さいプロジェクトを小さく回 せる。 ● これができないチームに大きいプロジェクトは任 せられない。 ● つまり、小さく回すことが出来ず、無駄に大きくし てしまう。 50
  51. 51. 常にグリーンになるテストの対処法 ● 1年以上、グリーンになるテストはUnitテストか ら外しても良い。 ● 開発中のテスト(特にTDD)は、フィードバックの スピードが重要。 ● つまりスコープを小さくするのが大切。 ● 常にグリーンになるテストがいるとフィードバック が遅くなる危険がある。 ● 重要なテストならば、リリース前にだけテスト確 認すれば良い 51
  52. 52. DDDの練習課題 DDDやプログラミングの練習には、ボブおじさん の「Bowling Game Kata」がオススメ。 http://butunclebob.com/ArticleS.UncleBob.Th eBowlingGameKata 52
  53. 53. デザインパターンについて デザインパターンなどのパターンは、形にはまる と強力だが、その本質を理解しないで利用すると 応用が利かない、歪んだ形となる事が多い。 パターンの本質を理解しないのなら、使わない方 がマシ。 53
  54. 54. インスタンス生成のコスト クラスからインスタンスを生成する際、容易に newしていませんか? 駐車場クラスを安易にnewしてませんでしたか? 現実はそんなに簡単に、駐車場は作られませ ん。それなりにコストが必要です。 DDD本にも、エンジンを作る工場の話がありま すが、役割(責務)だけでなく、生成コストも視野 に入れて、モデルを考えてみると良いですよ。 54
  55. 55. 自分のふりかえり 55
  56. 56. 自分のふりかえり ● DDDのリファクタリンクとはどのようなものか、 体験できたのは本当に貴重な経験となった。 ● コアドメインを探求する抽象化(または単純化) の感覚がまだ見えてこない。 なんかセンスが必要な気がしてきた・・・うーむ。 ● プログラムからのフィードバック重要。卓上のモ デル化だけでは見えてこない事が多い。 56
  57. 57. 自分のふりかえり ● 今回のワークショップとても勉強になったので、 是非またワークショップに参加してみたい。 ● でも、DDDのワークショップはなかなか見かけ られない状況。 ● DDDワークショップに興味を持った方は、 twitter: @kawakawa までご連絡下さい。 自身も初心者ながら、どのような形でワーク ショップが出来るのか、考えて行きたいです。 57

×