Download as PDF, PPTX
Uploaded byHiroshi Maekawa
ドメイン『駆動』『開発』
DevLOVE関西 「DDD（ドメイン駆動設計）実践者の話を聞いてみよう」でお話した内容です。 https://devlove-kansai.doorkeeper.jp/events/30012 前半はギルドワークスでのDDD実践の話、後半は@Posauneの解釈するDDDのお話になります。
More Related Content
ドメイン『駆動』『開発』
- 1.
- 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 #とは • ApplicationLifecycle Management • アプリケーションの一生を面倒見るお仕事 • どういう課題から、どういう要求が生まれて、 それをどう実現し、どう確認し、どう運用し、 どう役目を終わらせるか。 • （個人的解釈です）
- 5.
- 6. ALMエンジニアとしての最近 • ギルドワークスの現場コーチ • 飛び込みCIエンジニアとして主にiOS周りの ビルド環境を整備 •CI Serviceにゾッコン中 http://www.slideshare.net/Posaune/jenkinsci-50411288
- 7. 開発者としての最近 • Javaはなんとかかんとかドメイン駆動にしようと 四苦Hack中 • SwiftはクライアントサイドMVCで画面と実装を 分離させようと四苦Hack中 •どんなプロジェクトでも、ユーザに一歩踏み込んで 機能やデザイン（意匠）についてディスカッションしてい ます
- 8.
- 9.
- 10.
- 11.
- 12. エヴァンス本との出会い （一回目） • 頑張って読んだ、けれど・・・ • 正直ValueObjectくらいしか頭に残ってな かった（それもThought Worksアンソロジー で頭に入ってたのかも） • やっぱり、「これでやろう」とは思えず
- 13. エヴァンス本にすがる （二回目） • ある日、結構でかいめのソフトウェアの設計担当に。 • 所謂クライアントサイドMVCを採用したが、Model 層以下の組み方が分からず、画面とデータを直結しか ける •これではいかんとDDD本を読む • ようやくレイヤー化アーキテクチャの利点を知る
- 15. アプリケーション層重要 • ドメインをユーザインタフェースから分離す るにはこの一層が必要 • クライアントサイドMVCのMがいきなり ドメインオブジェクトと直結されがち •ドメインを隔離することの重要性に 気づきかける
- 16.
- 17.
- 18.
- 19. ギルドワークスのDDD事情 • 「誰かが一人頑張ればドメイン駆動設計でき る」なんてことは絶対にない • Ruby/ RoR でとにかく動くものを素早く作っ て行くのが主流のスタイルだった • ちょうど今その作り方の壁にぶち当たりつつ あるところ
- 20. DDDへの期待 • 技術的負債改善へのアプローチ • 素早く・安全な改良を行いたい •エンジニアがお客様の業務にもっと興味を もつように
- 21.
- 22.
- 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
- 28.
- 29.
- 30.
- 31.
- 32. 突然の(個人的)ブレイクスルー • ドメイン駆動設計の探求 其の一モデルと実装 を協調させる、とはどういうことか http://blog.guildworks.jp/2015/08/12/domain-driven-design-1/ • ドメインに「駆動」されて「設計」するとは どういうことか、という気付き
- 33.
- 34.
- 35.
- 36. 本当にそれ「駆動」されてる？ • TDD、BDD テストによってコードが駆動される • （狭義の）MDD モデリングによってコードが駆動される • DDD ドメインによって、設計書が駆動される？？
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 44.
- 46.
- 47.
- 48.
- 49. DDD is notonly Design !! • モデリングして、実装して、フィードバックを 受ける、というライフサイクルそのものが ドメイン駆動設計 • 「値オブジェクトとエンティティを分けた」 「レポジトリを使った」「レイヤ分割した」 だけではドメイン駆動設計ではない！
- 50.
- 51.
- 52.
- 53.
- 54. 核心にある複雑さに立ち向かう • お客さんの関心事で会話をする • お客さんの関心事でモデリングする •お客さんの関心事をソースコードにのせる • お客さんの関心事を常に探り続け、改善しつ づけ、洗練させ続ける
- 55.
- 56.
- 57.
- 58.
- 59.