Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DDDとは結局何なのか
Search
acomagu
July 18, 2020
Technology
0
350
DDDとは結局何なのか
200718 Zli x DMM 合同LT
acomagu
July 18, 2020
Tweet
Share
More Decks by acomagu
See All by acomagu
Stripe SSoT をするべきか否か
acomagu
0
52
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
97
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
93
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
310
Stripe リコンサイルの勘所
acomagu
0
490
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.2k
AWS CDK を支える Constructs について
acomagu
0
170
API Gateway HTTP API について
acomagu
0
140
JP_Stripes: 一貫性に寄与する設計
acomagu
0
97
Other Decks in Technology
See All in Technology
あなたのWebサービスはAIに自動テストしてもらえる?アクセシビリティツリーで読み解く、AIの『視点』
yusukeiwaki
1
3.1k
Where does my memory come from?
ennael
PRO
0
120
High performance GIF playback/iOSDC25
noppefoxwolf
1
180
Goのビルドシステムの変遷 / The history of Go's build system
ymotongpoo
12
3.3k
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
140
北海道の人に知ってもらいたいGISスポット / gis-spot-in-hokkaido-2025
sakaik
0
180
analysis パッケージの仕組みの上でMulti linter with configを実現する / Go Conference 2025
k1low
1
220
「技術負債にならない・間違えない」 権限管理の設計と実装
naro143
30
8.8k
Built to Rank: Why Your Hosting Stack Is an SEO Power Tool
rogermedia
0
120
施策が均質化する採用市場で何を捨て 何を大事にしていくかを考える
akyun
0
220
日経が挑戦するデータ民主化 ~ セルフサービス基盤がもたらす利点と苦悩~/nikkei-tech-talk-37
nikkei_engineer_recruiting
0
200
Go Conference 2025: GoのinterfaceとGenericsの内部構造と進化 / Go type system internals
ryokotmng
3
480
Featured
See All Featured
The Language of Interfaces
destraynor
162
25k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
How GitHub (no longer) Works
holman
315
140k
Building an army of robots
kneath
306
46k
Designing for humans not robots
tammielis
254
25k
Facilitating Awesome Meetings
lara
56
6.6k
Making the Leap to Tech Lead
cromwellryan
135
9.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
The Cost Of JavaScript in 2023
addyosmani
53
9k
Transcript
DDDとは結局何なのか @acomagu 200718 Zli x DMM合同LT会
今回の目的 DDD 本に載っていることを整理し、DDD の全体像を改めて見てみる DDD が言っていることと言っていないことを整理し、ありがちなクックブックから開放され る
DDD とは何か
DDD って何? - ドメインエキスパートとドメインモデルを議論すること? - Entity/Value Object? - リポジトリ/ファクトリ? -
ビジネスロジックを分けること? - コンテキストを分けること? - ユビキタス言語?
DDD って何? - ドメインエキスパートとドメインモデルを議論すること? - Entity/Value Object? - リポジトリ/ファクトリ? -
ビジネスロジックを分けること? - コンテキストを分けること? - ユビキタス言語? DDD 本にはめちゃめちゃいろいろ書いてある→
DDD って何? DDD本 序文 「先進的なソフトウェア設計者は、少なくともここ20年の間、ドメインモデリングと設計が 重大なテーマであると認識してきた。しかし、何をする必要があって、それをどのように すべきかについては、驚くほどわずかしか書かれていない。だが、明確に体系化されて はいないものの、オブジェクトコミュニティの底流として、ある哲学が出現してきている。 私はその哲学を、ドメイン駆動設計と呼んでいる。」
DDD って何? DDD本 序文 「先進的なソフトウェア設計者は、少なくともここ20年の間、ドメインモデリングと設計が 重大なテーマであると認識してきた。しかし、何をする必要があって、それをどのように すべきかについては、驚くほどわずかしか書かれていない。だが、明確に体系化されて はいないものの、オブジェクトコミュニティの底流として、ある哲学が出現してきている。 私はその哲学を、ドメイン駆動設計と呼んでいる。」 (よくわからない)
特定の手順や方法ではなさそう
DDD って何? Domain-Driven Design Reference より - コアドメインに集中する - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
- 境界付けられたコンテキストの中のユビキタス言語で話す
DDD って何? “Tackling Complexity in the Heart of Software” by
Eric Evans(DDD Europe 2016) より - ドメインの中核となる複雑さと機会に焦点を当てる - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する - 明示的にそれらのモデルを表現するソフトウェアを書く - 境界付けられたコンテキストの中のユビキタス言語で話す
DDD って何? Explore DDD 2018 “DDD Isn't Done: A Skeptical,
Optimistic , Pragmatic Look” より
DDD って何? Explore DDD 2018 “DDD Isn't Done: A Skeptical,
Optimistic , Pragmatic Look” より DDD はクックブックではない
DDD って何? Explore DDD 2018 “DDD Isn't Done: A Skeptical,
Optimistic , Pragmatic Look” より DDD は原則だ!
これこそが DDD “Tackling Complexity in the Heart of Software” by
Eric Evans(DDD Europe 2016) より - ドメインの中核となる複雑さと機会に焦点を当てる - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する - 明示的にそれらのモデルを表現するソフトウェアを書く - 境界付けられたコンテキストの中のユビキタス言語で話す
DDD 本の中に書いてあることって...?
DDD 本の中に書いてあることって? - ドメインエキスパートとドメインモデルを議論すること? - Entity/Value Object? - リポジトリ/ファクトリ? -
ビジネスロジックを分けること? - コンテキストを分けること? - ユビキタス言語? ↑これらは何なのか?
Domain-Driven Design Reference: Pattern Language Overview(vii ページ)より
Domain-Driven Design Reference: Pattern Language Overview(vii ページ)より
DDD 本の中でキーとなる用語 - モデル駆動設計 - ユビキタス言語 - 境界づけられたコンテキスト これらと「DDD の原則」を見比べていこう
モデル駆動開発 関連: E/VO、集約、オブジェクトのライフサイクル(、ドメインエキスパート) 原則: - “ドメインの中核となる複雑さと機会に焦点を当てる” - “ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する” - “明示的にそれらのモデルを表現するソフトウェアを書く”
DDD の中心となる考え方 モデルをドメインエキスパートと協業して作り上げ、それを表現するソフトウェアを書く。更に ドメイン領域を他の部分と分ける。 また、オブジェクトのライフサイクルと集約に関するパターンを含む
モデル駆動設計 所感 - もともとオブジェクト指向では、現実世界の物をヒントにモデリングをするというアイ ディアは一般的だった - 「業務内容の名詞をクラス名にする」とか聞いたことあるはず - DDD ではソフトウェア設計のなかでもドメインエキスパートと議論すべき部分を明確
にした
ユビキタス言語 関連: 境界づけられたコンテキスト、モデル駆動設計 原則: - “境界付けられたコンテキストの中のユビキタス言語で話す” チーム内(ドメインエキスパート含む)のコミュニケーションや、ソフトウェア内で必ず同じ 用語を使うということ ドメインエキスパートと開発者や、開発者同士の認識のずれを防ぐ モデルの進化はユビキタス言語の進化である
ユビキタス言語 所感 IDDD「Evans がソフトウェア開発コミュニティにもたらした『発明』をひとつあげるとすれ ば、それはユビキタス言語だ」 シンプルなアイディアだけど強力ですよね
境界づけられたコンテキスト 関連: コンテキスト間の関係、ユビキタス言語 原則: - “境界付けられたコンテキストの中のユビキタス言語で話す” いろいろな理由で分けられるモデルの境界 チームやステークホルダーの境界であり、言語の境界である。解決領域寄りの概念なの で(IDDD「境界づけられたコンテキストは特定のソリューションを表す」)、このコンテキス トがどの課題(ドメイン)に向けたものなのかを考えることが重要。
境界づけられたコンテキスト 所感 - IDDD「コンテキストは DDD の王様」 - 技術的な境界が必ずしもコンテキストを分けるわけではない(IDDD 2.4章)。しかし チームの境界はコンテキストを分ける。
- ユビキタス言語が重なったと言う理由だけでコンテキストを分けるのは早計だと思 います。既存のモデル内で複数のオブジェクトに分けるだけで解決できることもあり ます。 - コンテキストを分けるとデータの共有に課題が生じることが多いです(データベース の共有や非同期コミュニケーションが必要になる場合がある)。 - 例えば一般的にサーバーとフロントエンドは別のコンテキストと言えますし、外部ラ イブラリや外部サービスも別コンテキストと考えられます。
DDD まわりまとめ - モデル駆動開発 - ユビキタス言語 - 境界づけられたコンテキスト ↑これらが DDD
の原則を支える基本要素であり、より具体的な方法やパターンも含んで いる。
DDD が重視していないこと
DDD が重視していないこと 具体的なことはだいたい全部 - クリーンアーキテクチャ/ヘキサゴナルアーキテクチャ - ドメイン層は純粋関数にしなければならない - リポジトリはユースケース層のみで使う -
1つのマイクロサービスは1つのコンテキストにあたる - コンテキスト間の通信はユースケース層をまたがなければならない - 外部との通信はすべてリポジトリを通すべき ↑が間違いではないが、なぜそうするのかをしっかり理由づけするのが大切(でないと 後々自分で自分の首を絞めることになる)
おわりに
(最近の)感想 - DDD とはほぼ概念であり、いろいろな抽象的な思想や幅広い手法を含むので、何 を指すかわからないのでDDD という言葉単体では使わないほうがよさそう - 適切なモデリングをするためにはオブジェクト指向の経験が必須で、DDD を始める 前にオブジェクト指向でちゃんと設計したプログラムを作る練習がまず必要だなと
最近痛感している
まとめ DDD とは以下の4つの原則にまとめられる - ドメインの中核となる複雑さと機会に焦点を当てる - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する - 明示的にそれらのモデルを表現するソフトウェアを書く -
境界付けられたコンテキストの中のユビキタス言語で話す 上記の原則を支える概念は以下の3つにまとめられる - モデル駆動開発 - ユビキタス言語 - 境界づけられたコンテキスト
まとめ DDD を実践するなら、DDD で重視していることをしっかりと把握し、詳細に気を 取られすぎないことが大切
ありがとうございました!!