Implementing Domain-Driven Design: Part 1
Download as PPTX, PDF11 likes6,670 views
2013 年に出版された "Implementing Domain-Driven Design" の内容を解説します。第 1 回の今回は、大上段の「なぜ？」「いつ？」から初めて、DDD のイメージをつかむためのサンプルコードを見ていきます。
Implementing Domain-Driven Design: Part 1
- 1. Implementing Domain-Driven Design Part 1: Getting Started with DDD 神原 淳史 @atsukanrock 2015/08/07 今だから学びたい！DDD (Sansan .NET勉強会 #10)
- 2. 自己紹介 • 神原 淳史 @atsukanrock https://github.com/atsukanrock • Sansan株式会社 (2014年11月から) アバナード株式会社 (2011年7月～2014年10月) • Software Developer Domain-Driven Design / .NET / C# / Azure Cloud (´･ω･`)
- 6. From DDD to IDDD DDD published in 2004 IDDD published in 2013 コンセプトを提示 具体的な設計、Do / Don’tを提示 ベーシックでやや古いアーキテクチャ DDD発刊以降に出てきたアーキテクチャも導入 こいつの紹介
- 7. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 8. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 9. なぜDDDを採用するのか Why do we employ DDD?
- 10. DDDならできます できること 効果 Domain Expertsが持つ業務知識をモデル化 • 個々のDomain Expertに分散していた ノウハウの共有 • 担当者が変わってもすぐに使える 開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応 Domain Expertsですら気付かなかった 新たな知見の発見 ∵ (なぜならば) モデル化することで: • 「すぐに」「何度でも」シミュレーション可能 • 抽象化により本質が見える • 単なる業務自動化でなくシステムが 事業を引っ張る
- 11. 前提 • Domain Expertsはチームの一員となる • Agile / Scrum • Domain Expertsとチームは共通の言語 (Ubiquitous Language) 、共通のモデルを使って会話する • 「お客には設計の話なんてするな」ではない
- 12. とかゆってるけど • Domain Expert is どこ • チームの一員になってくれてモデルの話ができるひとって… • DDDはCore Domain (事業差別化領域) に適用してこそ 最大の効果 • 「どの領域をシステム化するか」の選択権って…
- 13. DDDの本質の実践は困難…
- 14. それでも自社サービスなら… • サービスの根幹部分がCore Domainになる • Domain Expertsには自分たちがなる • 外部アドバイザーとかは居るかもしれない
- 15. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 16. いつDDDを採用するのか When to employ DDD
- 17. 向き不向きがあります 複雑単純 長寿 短命 DDD 逃げる勇気 Access VBA とか？ Transaction Script / Table Module
- 18. The DDD Scorecard from IDDD • 一言で言うと: DDDは複雑で長寿なシステムの 場合に使うべきもの • CRUD中心のシステムなら Scaffoldingとかで作れば良い • あと、ゲームとか証券とか にはたぶん向かない
- 19. 向き不向きがあります 複雑単純 長寿 短命 DDD 逃げる勇気 Access VBA とか？ Transaction Script / Table Module 実際のシステム
- 20. 私見ですが • システム全体がDDDの使用が適切な特性を持っている わけではない (おそらくほぼ全てのシステムに言える) マスタ管理とか、単純なのがあるはず • DDDを採用するのは一部のCore Domainに絞って、 残りはScaffoldingとかTransaction Scriptで作れば良い 混ぜる勇気
- 21. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 22. IDDDの全体像 The whole picture of IDDD
- 23. ざっくり言うと • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション
- 24. 今回は時間の都合上 • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション ここと (説明済み) ここ (の一部) だけ
- 26. Domainの分割、Bounded Context • システム化対象領域を いかに分割するか • (今流行りの) Microservice にも通じる考え方
- 27. Architecture ※私の大好物 • Layers • Dependency Inversion Principle • Hexagonal / Ports and Adapters • Service-Oriented / REST • CQRS: Command-Query Responsibility Segregation • Event Sourcing and more…
- 28. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 29. DDDのモデリング手法 DDD style modeling technique
- 30. オブジェクトおよび概念 • Entity • Value Object • Service • Domain Event • Module • Aggregate • Factory • Repository New in IDDD
- 31. 正しく知り、使うことで • Domainの知識がモデルに集約される • UI側に散ったりしない • 不純物が混じらない • トランザクション • セキュリティ • アプリケーション要件 • SOLID Principlesを守れる • オブジェクト指向の超大事な原則5つ
- 32. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 33. Entity The core of domain modeling
- 34. A Poor Entity getter / setterのみのプロパティが並ぶ (単なるデータの入れ物) • SprintIdとStatusを合わせて設定すると いう知識がクライアントに • 実際にはValidationとかDB保存とか もっとやることが多い
- 35. A DDD Style Entity getter / setterのみのプロパティは 消えた 適切なValidation Domainの知識
- 36. Entity in IDDD • Identity大事 • 何をIdentityとするか • Identityが満たすべき要件 • Entityの生成 • コンストラクター • Factory
- 37. Entity in IDDD • Validation • Value Objectで守る • プロパティのSetterで守る • Validatorを切り出す • DBに行くようなValidationはしない (例: ユニークチェック) • Change Tracking
- 38. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 39. Value Object To enrich your entities
- 41. A sample Value Object Domainの知識
- 43. Value Object in IDDD • Identityを持つモノでなく、等価交換可能 • Immutable • Value Equality (implements IEquatable<T>) • Side-Effect-Free Behavior • Persisting Value Objects • DB等への保存
- 44. Value Object in IDDD • Entity’s Identity as Value Object • 単なるString等でなくXxxIdクラスを作る • (↑とはいえ) 何でもかんでもValue Objectにはしない • 複数の属性もしくは振る舞いを持つものだけ • それ以外はプリミティブ型で済ます
- 45. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 46. 少し複雑な例 (Application Service) A little bit complex example of Application Service
- 47. A sample Application Service DI前提 (changed from DDD) Query Service ※後述 Application Service • Domain Modelを使ってアプリケーション のトランザクションを実行 • 必要なセキュリティを実装
- 48. Domain Model in Application Service Entity Repository Value Object Service
- 49. Query Service? SQLベタ書き Application Layer of Hexagonal Architecture ※後述 • CQRS (次回以降のお話) のQuery Command (参照のみ) • データアクセスがRepositoryだけだとアプリケーション向け のQueryがしんどい (Join とかあって) EntityでなくData Transfer Objectを返す
- 50. Hexagonal Architecture? • 一言で言うと: Domain Modelさえ クリーンに保てば、 後は作りやすいように 作ればおｋ • DI (IoC) が前提になる • 詳しくは次回以降に…
- 51. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
- 52. まとめ Wrap up
- 53. まとめ • DDD採用の目的: システムの価値を上げる • そのために、Domainモデリングの手法を学ぶ • IDDDが具体的な指針を示した
- 54. 捕捉 • 図、サンプルコードは全てIDDDから拝借した https://github.com/VaughnVernon/IDDD_Samples_NET • 実はDomain Modelをクリーンに保つには、それ以外の ところ (例えばDBアクセス周り) に相当な工夫が必要 そのためDDDは、土台作りのための初期投資がかさんだり、 学習コストが高い問題があり、採用是非の見極めが重要
- 55. 次回以降何が聞きたい? 1. Domainモデリング手法をもっと詳しく 2. Architecture 3. Domainの分割、Bounded Contextの統合 4. もう聞きたくない