Tweet
Tweet

Slide 1

Slide 1 text

Implementing Domain-Driven Design Part 1: Getting Started with DDD 神原 淳史 @atsukanrock 2015/08/07 今だから学びたい！DDD (Sansan .NET勉強会 #10)

Slide 2

Slide 2 text

自己紹介 • 神原 淳史 @atsukanrock https://github.com/atsukanrock • Sansan株式会社 (2014年11月から) アバナード株式会社 (2011年7月～2014年10月) • Software Developer Domain-Driven Design / .NET / C# / Azure Cloud (´･ω･`)

Slide 3

Slide 3 text

今日のお題は… Today’s Contents

Slide 4

Slide 4 text

DDD: Domain-Driven Design

Slide 5

Slide 5 text

IDDD: Implementing DDD

Slide 6

Slide 6 text

From DDD to IDDD DDD published in 2004 IDDD published in 2013 コンセプトを提示 具体的な設計、Do / Don’tを提示 ベーシックでやや古いアーキテクチャ DDD発刊以降に出てきたアーキテクチャも導入 こいつの紹介

Slide 7

Slide 7 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 8

Slide 8 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 9

Slide 9 text

なぜDDDを採用するのか Why do we employ DDD?

Slide 10

Slide 10 text

DDDならできます できること 効果 Domain Expertsが持つ業務知識をモデル化 • 個々のDomain Expertに分散していた ノウハウの共有 • 担当者が変わってもすぐに使える 開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応 Domain Expertsですら気付かなかった 新たな知見の発見 ∵ (なぜならば) モデル化することで: • 「すぐに」「何度でも」シミュレーション可能 • 抽象化により本質が見える • 単なる業務自動化でなくシステムが 事業を引っ張る

Slide 11

Slide 11 text

前提 • Domain Expertsはチームの一員となる • Agile / Scrum • Domain Expertsとチームは共通の言語 (Ubiquitous Language) 、共通のモデルを使って会話する • 「お客には設計の話なんてするな」ではない

Slide 12

Slide 12 text

とかゆってるけど • Domain Expert is どこ • チームの一員になってくれてモデルの話ができるひとって… • DDDはCore Domain (事業差別化領域) に適用してこそ 最大の効果 • 「どの領域をシステム化するか」の選択権って…

Slide 13

Slide 13 text

DDDの本質の実践は困難…

Slide 14

Slide 14 text

それでも自社サービスなら… • サービスの根幹部分がCore Domainになる • Domain Expertsには自分たちがなる • 外部アドバイザーとかは居るかもしれない

Slide 15

Slide 15 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 16

Slide 16 text

いつDDDを採用するのか When to employ DDD

Slide 17

Slide 17 text

向き不向きがあります 複雑 単純 長寿 短命 DDD 逃げる勇気 Access VBA とか？ Transaction Script / Table Module

Slide 18

Slide 18 text

The DDD Scorecard from IDDD • 一言で言うと: DDDは複雑で長寿なシステムの 場合に使うべきもの • CRUD中心のシステムなら Scaffoldingとかで作れば良い • あと、ゲームとか証券とか にはたぶん向かない

Slide 19

Slide 19 text

向き不向きがあります 複雑 単純 長寿 短命 DDD 逃げる勇気 Access VBA とか？ Transaction Script / Table Module 実際のシステム

Slide 20

Slide 20 text

私見ですが • システム全体がDDDの使用が適切な特性を持っている わけではない (おそらくほぼ全てのシステムに言える) マスタ管理とか、単純なのがあるはず • DDDを採用するのは一部のCore Domainに絞って、 残りはScaffoldingとかTransaction Scriptで作れば良い 混ぜる勇気

Slide 21

Slide 21 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 22

Slide 22 text

IDDDの全体像 The whole picture of IDDD

Slide 23

Slide 23 text

ざっくり言うと • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション

Slide 24

Slide 24 text

今回は時間の都合上 • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション ここと (説明済み) ここ (の一部) だけ

Slide 25

Slide 25 text

IDDDは盛り沢山なので… 残りは次回以降に!! …だけどちょっとだけ

Slide 26

Slide 26 text

Domainの分割、Bounded Context • システム化対象領域を いかに分割するか • (今流行りの) Microservice にも通じる考え方

Slide 27

Slide 27 text

Architecture ※私の大好物 • Layers • Dependency Inversion Principle • Hexagonal / Ports and Adapters • Service-Oriented / REST • CQRS: Command-Query Responsibility Segregation • Event Sourcing and more…

Slide 28

Slide 28 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 29

Slide 29 text

DDDのモデリング手法 DDD style modeling technique

Slide 30

Slide 30 text

オブジェクトおよび概念 • Entity • Value Object • Service • Domain Event • Module • Aggregate • Factory • Repository New in IDDD

Slide 31

Slide 31 text

正しく知り、使うことで • Domainの知識がモデルに集約される • UI側に散ったりしない • 不純物が混じらない • トランザクション • セキュリティ • アプリケーション要件 • SOLID Principlesを守れる • オブジェクト指向の超大事な原則5つ

Slide 32

Slide 32 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 33

Slide 33 text

Entity The core of domain modeling

Slide 34

Slide 34 text

A Poor Entity getter / setterのみのプロパティが並ぶ (単なるデータの入れ物) • SprintIdとStatusを合わせて設定すると いう知識がクライアントに • 実際にはValidationとかDB保存とか もっとやることが多い

Slide 35

Slide 35 text

A DDD Style Entity getter / setterのみのプロパティは 消えた 適切なValidation Domainの知識

Slide 36

Slide 36 text

Entity in IDDD • Identity大事 • 何をIdentityとするか • Identityが満たすべき要件 • Entityの生成 • コンストラクター • Factory

Slide 37

Slide 37 text

Entity in IDDD • Validation • Value Objectで守る • プロパティのSetterで守る • Validatorを切り出す • DBに行くようなValidationはしない (例: ユニークチェック) • Change Tracking

Slide 38

Slide 38 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 39

Slide 39 text

Value Object To enrich your entities

Slide 40

Slide 40 text

もしValue Objectがなかったら EntityにDomainの知識を持たせる。 間違ってはいないが… プロパティがわらわらあって何かぼやけてる感じ ∵ ひとまとまりのコンセプトが他のコンテキストに 混じってしまっている

Slide 41

Slide 41 text

A sample Value Object Domainの知識

Slide 42

Slide 42 text

Value Objectのある世界 ひとまとまりのコンセプトが Value Objectにまとまった

Slide 43

Slide 43 text

Value Object in IDDD • Identityを持つモノでなく、等価交換可能 • Immutable • Value Equality (implements IEquatable) • Side-Effect-Free Behavior • Persisting Value Objects • DB等への保存

Slide 44

Slide 44 text

Value Object in IDDD • Entity’s Identity as Value Object • 単なるString等でなくXxxIdクラスを作る • (↑とはいえ) 何でもかんでもValue Objectにはしない • 複数の属性もしくは振る舞いを持つものだけ • それ以外はプリミティブ型で済ます

Slide 45

Slide 45 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 46

Slide 46 text

少し複雑な例 (Application Service) A little bit complex example of Application Service

Slide 47

Slide 47 text

A sample Application Service DI前提 (changed from DDD) Query Service ※後述 Application Service • Domain Modelを使ってアプリケーション のトランザクションを実行 • 必要なセキュリティを実装

Slide 48

Slide 48 text

Domain Model in Application Service Entity Repository Value Object Service

Slide 49

Slide 49 text

Query Service? SQLベタ書き Application Layer of Hexagonal Architecture ※後述 • CQRS (次回以降のお話) のQuery Command (参照のみ) • データアクセスがRepositoryだけだとアプリケーション向け のQueryがしんどい (Join とかあって) EntityでなくData Transfer Objectを返す

Slide 50

Slide 50 text

Hexagonal Architecture? • 一言で言うと: Domain Modelさえ クリーンに保てば、 後は作りやすいように 作ればおｋ • DI (IoC) が前提になる • 詳しくは次回以降に…

Slide 51

Slide 51 text

Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

Slide 52

Slide 52 text

まとめ Wrap up

Slide 53

Slide 53 text

まとめ • DDD採用の目的: システムの価値を上げる • そのために、Domainモデリングの手法を学ぶ • IDDDが具体的な指針を示した

Slide 54

Slide 54 text

捕捉 • 図、サンプルコードは全てIDDDから拝借した https://github.com/VaughnVernon/IDDD_Samples_NET • 実はDomain Modelをクリーンに保つには、それ以外の ところ (例えばDBアクセス周り) に相当な工夫が必要 そのためDDDは、土台作りのための初期投資がかさんだり、 学習コストが高い問題があり、採用是非の見極めが重要

Slide 55

Slide 55 text

次回以降何が聞きたい? 1. Domainモデリング手法をもっと詳しく 2. Architecture 3. Domainの分割、Bounded Contextの統合 4. もう聞きたくない