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(ドメイン駆動設計)に参加してみました

0 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

×