Weitere ähnliche Inhalte
Ähnlich wie Implementing Domain-Driven Design: Part 1 (20)
Kürzlich hochgeladen (10)
Implementing Domain-Driven Design: Part 1
- 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分)
- 10. DDDならできます
できること 効果
Domain Expertsが持つ業務知識をモデル化 • 個々のDomain Expertに分散していた
ノウハウの共有
• 担当者が変わってもすぐに使える
開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応
Domain Expertsですら気付かなかった
新たな知見の発見
∵ (なぜならば)
モデル化することで:
• 「すぐに」「何度でも」シミュレーション可能
• 抽象化により本質が見える
• 単なる業務自動化でなくシステムが
事業を引っ張る
- 12. とかゆってるけど
• Domain Expert is どこ
• チームの一員になってくれてモデルの話ができるひとって…
• DDDはCore Domain (事業差別化領域) に適用してこそ
最大の効果
• 「どの領域をシステム化するか」の選択権って…
- 15. Table of Contents
• なぜDDDを採用するのか (3分)
• いつDDDを採用するのか (2分)
• IDDDの全体像 (5分)
• DDDのモデリング手法 (2分)
• Entity (5分)
• Value Object (資料のみ)
• 少し複雑な例 (Application Service) (5分)
• まとめ (3分)
- 18. The DDD Scorecard from IDDD
• 一言で言うと:
DDDは複雑で長寿なシステムの
場合に使うべきもの
• CRUD中心のシステムなら
Scaffoldingとかで作れば良い
• あと、ゲームとか証券とか
にはたぶん向かない
- 21. Table of Contents
• なぜDDDを採用するのか (3分)
• いつDDDを採用するのか (2分)
• IDDDの全体像 (5分)
• DDDのモデリング手法 (2分)
• Entity (5分)
• Value Object (資料のみ)
• 少し複雑な例 (Application Service) (5分)
• まとめ (3分)
- 23. ざっくり言うと
• 概論 (Why / When / How)
• Domainの分割、Bounded Context
• Architecture
• Domainモデリングの手法
• Bounded Contextの統合
• アプリケーション
- 24. 今回は時間の都合上
• 概論 (Why / When / How)
• Domainの分割、Bounded Context
• Architecture
• Domainモデリングの手法
• Bounded Contextの統合
• アプリケーション
ここと (説明済み)
ここ (の一部) だけ
- 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分)
- 32. Table of Contents
• なぜDDDを採用するのか (3分)
• いつDDDを採用するのか (2分)
• IDDDの全体像 (5分)
• DDDのモデリング手法 (2分)
• Entity (5分)
• Value Object (資料のみ)
• 少し複雑な例 (Application Service) (5分)
• まとめ (3分)
- 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分)
- 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分)
- 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を返す
- 51. Table of Contents
• なぜDDDを採用するのか (3分)
• いつDDDを採用するのか (2分)
• IDDDの全体像 (5分)
• DDDのモデリング手法 (2分)
• Entity (5分)
• Value Object (資料のみ)
• 少し複雑な例 (Application Service) (5分)
• まとめ (3分)