ImplementingDomain-Driven Design
Part 1: Getting Started with DDD
神原 淳史@atsukanrock
2015/08/07今だから学びたい! DDD (Sansan .NET 勉強会 #10)
自己紹介
•神原 淳史 @atsukanrockhttps://github.com/atsukanrock
• Sansan 株式会社 (2014 年 11 月から )
アバナード株式会社 (2011 年 7 月~ 2014 年 10 月 )
• Software DeveloperDomain-Driven Design / .NET / C# / Azure Cloud (´ ・ω ・ `)
From DDD to IDDD
DDD published in 2004 IDDD published in 2013
コンセプトを提示 具体的な設計、 Do / Don’t を提示
ベーシックでやや古いアーキテクチャ DDD 発刊以降に出てきたアーキテクチャも導入
こいつの紹介
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
DDD ならできます
できること 効果
Domain Experts が持つ業務知識をモデル化
• 個々の Domain Expert に分散していたノウハウの共有
• 担当者が変わってもすぐに使える
開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応
Domain Experts ですら気付かなかった新たな知見の発見
∵ ( なぜならば )
モデル化することで :• 「すぐに」「何度でも」シミュレーション可能• 抽象化により本質が見える
• 単なる業務自動化でなくシステムが事業を引っ張る
前提
•Domain Experts はチームの一員となる• Agile / Scrum
•Domain Experts とチームは共通の言語 (Ubiquitous Language) 、共通のモデルを使って会話する• 「お客には設計の話なんてするな」ではない
とかゆってるけど
•Domain Expert is どこ• チームの一員になってくれてモデルの話ができるひとって
…
•DDD は Core Domain ( 事業差別化領域 ) に適用してこそ最大の効果• 「どの領域をシステム化するか」の選択権って…
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
The DDD Scorecard from IDDD
•一言で言うと :DDD は複雑で長寿なシステムの場合に使うべきもの
• CRUD 中心のシステムならScaffolding とかで作れば良い
•あと、ゲームとか証券とかにはたぶん向かない
私見ですが
•システム全体が DDD の使用が適切な特性を持っているわけではない ( おそらくほぼ全てのシステムに言える )
マスタ管理とか、単純なのがあるはず
•DDD を採用するのは一部の Core Domain に絞って、残りは Scaffolding とか Transaction Script で作れば良い
混ぜる勇気
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
ざっくり言うと
•概論 (Why / When / How)
•Domain の分割、 Bounded Context
• Architecture
•Domain モデリングの手法
• Bounded Context の統合
•アプリケーション
今回は時間の都合上
•概論 (Why / When / How)
•Domain の分割、 Bounded Context
• Architecture
•Domain モデリングの手法
• Bounded Context の統合
•アプリケーション
ここと (説明済み )
ここ ( の一部 ) だけ
Architecture ※ 私の大好物
• Layers
• Dependency Inversion Principle
• Hexagonal / Ports and Adapters
• Service-Oriented / REST
• CQRS: Command-Query Responsibility Segregation
• Event Sourcing
and more…
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
オブジェクトおよび概念
• Entity
• Value Object
• Service
• Domain Event
• Module
• Aggregate
• Factory
• Repository
New in IDDD
正しく知り、使うことで
• Domain の知識がモデルに集約される• UI側に散ったりしない
•不純物が混じらない• トランザクション• セキュリティ• アプリケーション要件
• SOLID Principles を守れる• オブジェクト指向の超大事な原則 5 つ
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
A Poor Entitygetter / setter のみのプロパティが並ぶ ( 単なるデータの入れ物 )
• SprintId と Status を合わせて設定するという知識がクライアントに
• 実際には Validation とか DB保存とかもっとやることが多い
Entity in IDDD
• Validation
• Value Object で守る
• プロパティの Setter で守る
• Validator を切り出す
• DB に行くような Validation はしない ( 例 : ユニークチェック )
• Change Tracking
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
もし Value Object がなかったら
Entity に Domain の知識を持たせる。
間違ってはいないが…
プロパティがわらわらあって何かぼやけてる感じ∵ひとまとまりのコンセプトが他のコンテキストに混じってしまっている
Value Object in IDDD
• Identity を持つモノでなく、等価交換可能
• Immutable
• Value Equality (implements IEquatable<T>)
• Side-Effect-Free Behavior
• Persisting Value Objects• DB等への保存
Value Object in IDDD
• Entity’s Identity as Value Object• 単なる String等でなく XxxId クラスを作る
• (↑ とはいえ ) 何でもかんでも Value Object にはしない• 複数の属性もしくは振る舞いを持つものだけ
• それ以外はプリミティブ型で済ます
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
A sample Application Service
DI 前提 (changed from DDD)
Query Service ※後述
Application Service
• Domain Model を使ってアプリケーションのトランザクションを実行
• 必要なセキュリティを実装
Query Service?
SQL ベタ書き
Application Layer of Hexagonal Architecture ※後述
• CQRS (次回以降のお話 ) の Query Command (参照のみ )
• データアクセスが Repository だけだとアプリケーション向けの Query がしんどい (Join とかあって )
Entity でなく Data Transfer Object を返す
Table of Contents
• なぜ DDD を採用するのか (3 分 )
• いつ DDD を採用するのか (2 分 )
• IDDD の全体像 (5 分 )
• DDD のモデリング手法 (2 分 )
• Entity (5 分 )
• Value Object ( 資料のみ )
• 少し複雑な例 (Application Service) (5 分 )
• まとめ (3 分 )
捕捉
•図、サンプルコードは全て IDDD から拝借した
https://github.com/VaughnVernon/IDDD_Samples_NET
•実は Domain Model をクリーンに保つには、それ以外のところ ( 例えば DB アクセス周り ) に相当な工夫が必要
そのため DDD は、土台作りのための初期投資がかさんだり、学習コストが高い問題があり、採用是非の見極めが重要