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 (´ ･ω ･ `)

今日のお題は…Today’s Contents

DDD: Domain-Driven Design

IDDD: Implementing DDD

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 を採用するのかWhy do we employ DDD?

DDD ならできます

できること 効果

Domain Experts が持つ業務知識をモデル化

• 個々の Domain Expert に分散していたノウハウの共有

• 担当者が変わってもすぐに使える

開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応

Domain Experts ですら気付かなかった新たな知見の発見

∵ ( なぜならば )

モデル化することで :• 「すぐに」「何度でも」シミュレーション可能• 抽象化により本質が見える

• 単なる業務自動化でなくシステムが事業を引っ張る

前提

•Domain Experts はチームの一員となる• Agile / Scrum

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

とかゆってるけど

•Domain Expert is どこ• チームの一員になってくれてモデルの話ができるひとって

…

•DDD は Core Domain ( 事業差別化領域 ) に適用してこそ最大の効果• 「どの領域をシステム化するか」の選択権って…

DDD の本質の実践は困難…

それでも自社サービスなら…

•サービスの根幹部分が Core Domain になる

•Domain Experts には自分たちがなる• 外部アドバイザーとかは居るかもしれない

Table of Contents

• なぜ DDD を採用するのか (3 分 )

• いつ DDD を採用するのか (2 分 )

• IDDD の全体像 (5 分 )

• DDD のモデリング手法 (2 分 )

• Entity (5 分 )

• Value Object ( 資料のみ )

• 少し複雑な例 (Application Service) (5 分 )

• まとめ (3 分 )

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

向き不向きがあります

複雑単純

長寿

短命

DDD

逃げる勇気Access VBA

とか？

Transaction Script / Table

Module

The DDD Scorecard from IDDD

•一言で言うと :DDD は複雑で長寿なシステムの場合に使うべきもの

• CRUD 中心のシステムならScaffolding とかで作れば良い

•あと、ゲームとか証券とかにはたぶん向かない

向き不向きがあります

複雑単純

長寿

短命

DDD

逃げる勇気Access VBA

とか？

Transaction Script / Table

Module

実際のシステム

私見ですが

•システム全体が 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 分 )

IDDD の全体像The whole picture of IDDD

ざっくり言うと

•概論 (Why / When / How)

•Domain の分割、 Bounded Context

• Architecture

•Domain モデリングの手法

• Bounded Context の統合

•アプリケーション

今回は時間の都合上

•概論 (Why / When / How)

•Domain の分割、 Bounded Context

• Architecture

•Domain モデリングの手法

• Bounded Context の統合

•アプリケーション

ここと (説明済み )

ここ ( の一部 ) だけ

IDDD は盛り沢山なので…

残りは次回以降に !!

… だけどちょっとだけ

Domain の分割、 Bounded Context

•システム化対象領域をいかに分割するか

• ( 今流行りの ) Microserviceにも通じる考え方

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 分 )

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

オブジェクトおよび概念

• 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 分 )

EntityThe core of domain modeling

A Poor Entitygetter / setter のみのプロパティが並ぶ ( 単なるデータの入れ物 )

• SprintId と Status を合わせて設定するという知識がクライアントに

• 実際には Validation とか DB保存とかもっとやることが多い

A DDD Style Entitygetter / setter のみのプロパティは消えた

適切な Validation

Domain の知識

Entity in IDDD

• Identity 大事• 何を Identity とするか

• Identity が満たすべき要件

• Entity の生成• コンストラクター

• Factory

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 ObjectTo enrich your entities

もし Value Object がなかったら

Entity に Domain の知識を持たせる。

間違ってはいないが…

プロパティがわらわらあって何かぼやけてる感じ∵ひとまとまりのコンセプトが他のコンテキストに混じってしまっている

A sample Value Object

Domain の知識

Value Object のある世界

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

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 分 )

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

A sample Application Service

DI 前提 (changed from DDD)

Query Service ※後述

Application Service

• Domain Model を使ってアプリケーションのトランザクションを実行

• 必要なセキュリティを実装

Domain Model in Application Service

Entity

Repository

Value Object

Service

Query Service?

SQL ベタ書き

Application Layer of Hexagonal Architecture ※後述

• CQRS (次回以降のお話 ) の Query Command (参照のみ )

• データアクセスが Repository だけだとアプリケーション向けの Query がしんどい (Join とかあって )

Entity でなく Data Transfer Object を返す

Hexagonal Architecture?

•一言で言うと :Domain Modelさえクリーンに保てば、後は作りやすいように作ればおｋ

•DI (IoC) が前提になる•詳しくは次回以降に…

Table of Contents

• なぜ DDD を採用するのか (3 分 )

• いつ DDD を採用するのか (2 分 )

• IDDD の全体像 (5 分 )

• DDD のモデリング手法 (2 分 )

• Entity (5 分 )

• Value Object ( 資料のみ )

• 少し複雑な例 (Application Service) (5 分 )

• まとめ (3 分 )

まとめWrap up

まとめ

•DDD 採用の目的 : システムの価値を上げる

•そのために、 Domain モデリングの手法を学ぶ

• IDDD が具体的な指針を示した

捕捉

•図、サンプルコードは全て IDDD から拝借した

https://github.com/VaughnVernon/IDDD_Samples_NET

•実は Domain Model をクリーンに保つには、それ以外のところ ( 例えば DB アクセス周り ) に相当な工夫が必要

そのため DDD は、土台作りのための初期投資がかさんだり、学習コストが高い問題があり、採用是非の見極めが重要

次回以降何が聞きたい ?

1. Domain モデリング手法をもっと詳しく

2. Architecture

3. Domain の分割、 Bounded Context の統合

4. もう聞きたくない