ドメイン『駆動』『開発』
•
23 likes•9,985 views
DevLOVE関西 「DDD（ドメイン駆動設計）実践者の話を聞いてみよう」でお話した内容です。 https://devlove-kansai.doorkeeper.jp/events/30012 前半はギルドワークスでのDDD実践の話、後半は@Posauneの解釈するDDDのお話になります。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ドメイン『駆動』『開発』
Similar to ドメイン『駆動』『開発』 (20)
More from Hiroshi Maekawa
More from Hiroshi Maekawa (18)
Recently uploaded
Recently uploaded (10)
ドメイン『駆動』『開発』
- 1. ドメイン 「駆動」「開発」 ギルドワークス株式会社 前川 博志 a.k.a @Posaune
- 2. 自己紹介 • 前川博志 a.k.a @Posaune • もともと老舗メーカでWindowプログラマ ギルドワークス株式会社所属ALMエンジニア • Microsoft MVP for Visual Studio ALM
- 3. 告知 • 第28回 TFSUG大阪 継続的デリバリーを実現する Team Foundation Server / Visual Studio Online 特集 https://tfsug.doorkeeper.jp/events/31243
- 4. ALM #とは • Application Lifecycle Management • アプリケーションの一生を面倒見るお仕事 • どういう課題から、どういう要求が生まれて、 それをどう実現し、どう確認し、どう運用し、 どう役目を終わらせるか。 • （個人的解釈です）
- 6. ALMエンジニアとしての最近 • ギルドワークスの現場コーチ • 飛び込みCIエンジニアとして主にiOS周りの ビルド環境を整備 • CI Serviceにゾッコン中 http://www.slideshare.net/Posaune/jenkinsci-50411288
- 7. 開発者としての最近 • Javaはなんとかかんとかドメイン駆動にしようと 四苦Hack中 • SwiftはクライアントサイドMVCで画面と実装を 分離させようと四苦Hack中 • どんなプロジェクトでも、ユーザに一歩踏み込んで 機能やデザイン（意匠）についてディスカッションしてい ます
- 9. こっから本題
- 11. DDDと出会う • 最初の出会いは進められて読んだInfoQのDDD冊子 （正直つらかった） • 読み進む中で増田さんのBlogを 発見（そっちは何とか分かる） • とはいえ、実践で使うには至らず
- 12. エヴァンス本との出会い （一回目） • 頑張って読んだ、けれど・・・ • 正直Value Objectくらいしか頭に残ってな かった（それもThought Worksアンソロジー で頭に入ってたのかも） • やっぱり、「これでやろう」とは思えず
- 13. エヴァンス本にすがる （二回目） • ある日、結構でかいめのソフトウェアの設計担当に。 • 所謂クライアントサイドMVCを採用したが、Model 層以下の組み方が分からず、画面とデータを直結しか ける • これではいかんとDDD本を読む • ようやくレイヤー化アーキテクチャの利点を知る
- 15. アプリケーション層重要 • ドメインをユーザインタフェースから分離す るにはこの一層が必要 • クライアントサイドMVCのMがいきなり ドメインオブジェクトと直結されがち • ドメインを隔離することの重要性に 気づきかける
- 16. そしてギルドワークスへ
- 17. ギルドワークスとDDD
- 19. ギルドワークスのDDD事情 • 「誰かが一人頑張ればドメイン駆動設計でき る」なんてことは絶対にない • Ruby / RoR でとにかく動くものを素早く作っ て行くのが主流のスタイルだった • ちょうど今その作り方の壁にぶち当たりつつ あるところ
- 20. DDDへの期待 • 技術的負債改善へのアプローチ • 素早く・安全な改良を行いたい • エンジニアがお客様の業務にもっと興味を もつように
- 23. DDDを広めるための取り組み • ドメインの言葉で会話をする • モデリングセッション • “DDD Boot” （考え中） • ちくちく設計鍛錬場
- 24. ドメインの言葉で会話する • Slackで技術者の言葉のみで会話してしまう • ほうっておくと、言われたままの設計で作る 技術者に成り下がってしまう • 気をつけないと、gemやライブラリ名や 代名詞で会話してしまう
- 25. こんな感じ • 「devise gem を導入します」 • 「なにそれ。何のために使うの？」 • 「 ユーザーのログイン時にメールでリマインダ 投げる所の実装です。deviseが楽かなぁと」
- 26. モデリングセッション • 開発者全員でモデリングをして意識をあわせ ておく • 可能なら、クライアントさんにも入って もらい、言葉をあわせていく。 • できるならその場で集まって、ダメなら オンラインで共有しながら
- 27. DDD Boot • DDDをちゃんとすると、面倒くさい。 (初期実装でのRoR / gem での立ち上がりにかなわない) • とはいえ、作るのってWeb と REST APIくらいなんだよねぇ • というわけで、テンプレート欲しい • （簡単なのは）もうあるよ https://github.com/system-sekkei/isolating-the-domain
- 29. 「ちくちく読む」とは • 一回（1時間30分くらい）で大体2段落くらい しか進まない • 増田さんセレクトのエッセンスとなる部分を 要約し、表す意味をじっくり考える • 必要に応じて、原著も参照する。
- 30. ちくちく読んでいる様子
- 31. @Posaune の考えるDDD
- 32. 突然の(個人的)ブレイクスルー • ドメイン駆動設計の探求 其の一 モデルと実装 を協調させる、とはどういうことか http://blog.guildworks.jp/2015/08/12/domain-driven-design-1/ • ドメインに「駆動」されて「設計」するとは どういうことか、という気付き
- 33. 皆さんにとって設計とは？
- 35. 「コード」ですよね！
- 36. 本当にそれ「駆動」されてる？ • TDD、BDD テストによってコードが駆動される • （狭義の）MDD モデリングによってコードが駆動される • DDD ドメインによって、設計書が駆動される？？
- 39. しかし現実は・・・
- 47. これは「設計」なんだろうか？
- 49. DDD is not only Design !! • モデリングして、実装して、フィードバックを 受ける、というライフサイクルそのものが ドメイン駆動設計 • 「値オブジェクトとエンティティを分けた」 「レポジトリを使った」「レイヤ分割した」 だけではドメイン駆動設計ではない！
- 50. なんのためにDDDするのか
- 54. 核心にある複雑さに立ち向かう • お客さんの関心事で会話をする • お客さんの関心事でモデリングする • お客さんの関心事をソースコードにのせる • お客さんの関心事を常に探り続け、改善しつ づけ、洗練させ続ける
- 56. 今の状況
- 59. Enjoy, Software Development !!