Implementing Domain-Driven Design: Part 1

2015年8月に私が公開したスライドです。長らくSlideShareに配置していましたが、SlideShareが広告まみれになって酷いので、Speaker Deckに移しました。以下、公開時の紹介文です。

---

2013 年に出版された "Implementing Domain-Driven Design" の内容を解説します。第 1 回の今回は、大上段の「なぜ？」「いつ？」から初めて、DDD のイメージをつかむためのサンプルコードを見ていきます。

Transcript

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 (´･ω･`)
3. 今日のお題は… Today’s Contents
4. DDD: Domain-Driven Design
5. IDDD: Implementing DDD
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の統合 • アプリケーション ここと (説明済み) ここ (の一部) だけ
25. IDDDは盛り沢山なので… 残りは次回以降に!! …だけどちょっとだけ
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
40. もしValue Objectがなかったら EntityにDomainの知識を持たせる。 間違ってはいないが… プロパティがわらわらあって何かぼやけてる感じ ∵ ひとまとまりのコンセプトが他のコンテキストに 混じってしまっている
41. A sample Value Object Domainの知識
42. Value Objectのある世界 ひとまとまりのコンセプトが Value Objectにまとまった
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. もう聞きたくない