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をDDDにするのか / what make DDD to DDD ?
Search
philomagi
January 18, 2020
Programming
9
3.5k
何がDDDをDDDにするのか / what make DDD to DDD ?
DDDを学習・実践において多く見受けられる混乱と、それに対する現時点での自分の回答
philomagi
January 18, 2020
Tweet
Share
More Decks by philomagi
See All by philomagi
ドメイン駆動設計のホーリズム的側面 / domain-driven-design and holism
tooppoo
0
190
アート、サイエンス、「わかりやすさ」 / art, science, "easy to understand"
tooppoo
1
20k
ソフトウェアと「動的平衡」 / software-and-dynamic-equilibrium
tooppoo
1
1k
javascriptでも条件式を使いたい話 / want to use conditional expression in javascript
tooppoo
0
6.4k
Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component
tooppoo
4
3.6k
技術書・方法論とのお付き合い / how to learn theory
tooppoo
4
1.2k
「オブジェクト指向」を再考する / reconsider "object-oriented"
tooppoo
2
820
「モデル」の二面性と設計を考える / dual nature of "model"
tooppoo
2
1.8k
「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain
tooppoo
9
2.9k
Other Decks in Programming
See All in Programming
Ruby×iOSアプリ開発 ~共に歩んだエコシステムの物語~
temoki
0
350
Navigation 2 を 3 に移行する(予定)ためにやったこと
yokomii
0
340
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
230
個人開発で徳島大学生60%以上の心を掴んだアプリ、そして手放した話
akidon0000
1
140
「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
taitotnk
0
870
The Past, Present, and Future of Enterprise Java with ASF in the Middle
ivargrimstad
0
160
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
4
1.5k
testingを眺める
matumoto
1
140
旅行プランAIエージェント開発の裏側
ippo012
2
920
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.9k
Zendeskのチケットを Amazon Bedrockで 解析した
ryokosuge
3
320
Design Foundational Data Engineering Observability
sucitw
3
200
Featured
See All Featured
Building Applications with DynamoDB
mza
96
6.6k
Code Reviewing Like a Champion
maltzj
525
40k
Rails Girls Zürich Keynote
gr2m
95
14k
How GitHub (no longer) Works
holman
315
140k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Agile that works and the tools we love
rasmusluckow
330
21k
We Have a Design System, Now What?
morganepeng
53
7.8k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
Designing for humans not robots
tammielis
253
25k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
530
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Transcript
何が“DDD”を”DDD”にするのか 2020/01/18 学生と社会人のライトニングトーク大会 #北海道LT大会 @Philomagi 1
発表者 @Philomagi • 主にフロントエンド主体のWEB系エンジニア • ScalaとTypescriptが好き • PHPは中々縁が切れない悪友 ◦ 最近は、「然程悪いやつでもないな」と思い始めてる
2
概要 • ドメイン駆動設計(DDD) • DDDを取り巻く混乱 • “DDD”を”DDD”足らしめるモノ • まとめ 3
ドメイン駆動設計 Domain-Driven Design(DDD) 4
ドメイン駆動設計 5
DDD is 何? 6 • ソフトウェア設計の方法論 • Eric Evansによる提唱 •
「ユーザー要求の問題解決にフォーカスした設計パターン」(日本 語版帯より) • 「ドメイン駆動設計、略してDDDと呼ばれるソフトウェア開発手法 がある。(中略)これをうまく使いこなせば、設計した結果が、その ソフトウェアの動作を明確に表すようになる。」(「実践ドメイン駆動 設計 」p.1)
DDDを取り巻く混乱 7
DDDを取り巻く混乱 8 • 「Entity」「Value Object」「Service」を使えばDDD? • 「Entity」(略)を使わなかったらDDDではない? • ドメインモデルを書いたらDDD? •
ドメイン分析したらDDD?
DDDを取り巻く混乱 9 • 「Entity」「Value Object」「Service」を使えばDDD? • 「Entity」(略)を使わなかったらDDDではない? • ドメインモデルを書いたらDDD? •
ドメイン分析したらDDD?
DDDとパターン 10 DDDは実装パターン集ではない • 各種パターンは、モデルと実装を紐付けるための 道具でしかない • DDD本のパターンを一切使わないDDDも、原理上 は考え得る
DDDとドメイン/ドメインモデル 11 ドメイン/ドメインモデルはDDD固有の概念ではない • ドメイン/ドメインモデルは、DDD以前から存在し、かつDDD 以外でも有効な概念 • ドメイン/ドメインモデルはDDDと他の方法論を区別する基準 にはならない •
故に、ドメイン/ドメインモデルを考えればDDDになるのでも ない
何が”DDD”なのか? 12 「DDDって何をどうすればDDDなの?」 「自分たちのやり方はDDDなの?」
脱線:ドメイン・DDD・「コスト」 13 • ドメイン = 問題領域。ソフトウェアで解決したい問題。 • ドメインの分析と理解は、DDDであろうとなかろうと、ソフトウェア 開発にとって一般に重要な課題。 •
「DDDは高コスト」→ そこで言う「コスト」は何か? • ドメインの分析・理解を指して「コスト」と語るなら、それはDDDでな くても払うべきコスト。 • 「DDDを使わない」は「ドメインの分析・理解を省略する」と同義で はないし、省略の理由にもならない
何が”DDD”を”DDD”足らしめるのか 14
何が”DDD”を”DDD”足らしめるのか 15 換言すれば DDDで外してはいけない核心は何か DDDと他の方法論の決定的な違いは何か
何が”DDD”を”DDD”足らしめるのか 16 ❌ Entity等のパターン ◦ 単なる道具の一種であり、DDDの構成要件でも、DDD固有の概念 でもない ❌ ドメインモデル ◦
DDD固有の概念でなく、DDD以外でも利用可能 ❌ ドメイン分析 ◦ DDD固有の概念でなく、ソフトウェア開発一般で必要かつ重要なプ ロセス
何が”DDD”を”DDD”足らしめるのか このスライドでは • ドメインに基づく概念/実装の単一モデル • 単一モデルを介したドメイン-ソフトウェア間の相互フィード バック の実践によって「DDDが成立する」と考える 17
ドメインに基づく概念/実装の単一モデル 18 業務知識 業務フロー ステークホルダー 課題 制約 ドメイン
ドメインに基づく概念/実装の単一モデル 19 業務知識 業務フロー ステークホルダー 課題 制約 ドメイン モデル
単一モデルを介したコミュニケーション 20
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 21 ドメイン ソフトウェア XにはX’とX’’の他に X’’’があります XはYの他にZ でも必要です X
X’’ Y X’
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 22 ドメイン ソフトウェア X X’’ Y X’ X’’
Z フィードバックに基 づくモデル更新
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 23 ドメイン ソフトウェア X X’’ Y X’ X’’
Z モデル更新に伴う 実装の更新
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 24 ドメイン ソフトウェア X X’’ Y X’ X’’
Z Xを具体的にどうする か、YとZでそれぞれ ルール同じ?
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 25 ドメイン ソフトウェア X X’’ Y X’ X’’
Z Xルール フィードバックに基 づくモデル更新
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 26 ドメイン ソフトウェア X X’’ Y X’ X’’
Z Xルール そうですね、その ルールはZと普段呼 んでいます
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 27 ドメイン ソフトウェア X X’’ Y X’ X’’
Z Z フィードバックに基 づくモデル更新
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 28 ドメイン ソフトウェア X X’’ Y X’ X’’
Z Z モデル更新に伴う 実装の更新
単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 29 ソフトウェア ドメイン 単一モデル
ドメイン駆動設計(日本語版) p.510より 本書にあるテクニックをすべて採用するプロジェクトなどないだろう。それで も、ドメイン駆動設計を真剣に行っているプロジェクトはすべて、何らかのか たちでそれとわかるようになる。 決定的な特徴は、対象となるドメインを理解し、その理解をソフトウェアにお いて具現化することを重視することにある。 - 「エリック・エヴァンスのドメイン駆動設計」 p.510
30
何が”DDD”を”DDD”足らしめるのか • ドメインに基づく概念/実装の単一モデル • 単一モデルを介したドメイン-ソフトウェア間の相互フィード バック の実践によって、「対象となるドメインを理解し、その理解をソフ トウェアにおいて具現化する」こと。 31
まとめ 32
何が”DDD”を”DDD”足らしめるのか • パターンやモデルそのものは、DDDの根幹ではない • “DDD”を”DDD”足らしめるのは ◦ ドメインに基づく単一モデル ◦ 単一モデルを介した相互フィードバック ◦
↑の実践によるドメインの理解と、その理解が反映された ソフトウェア 33
最後に 34 • 具体的なHowだけでなく、根幹にある思想・理論 = Whyもちゃんと考えてみる。 • Whyを理解してれば、広く応用が効く。 Howだ けだと、違うケースに対応し難い。 •
Whyを考えると、視点・考え方が広がる。
参考にした資料 35 • エリック・エヴァンスのドメイン駆動設計 (Eric Evans) • 実践ドメイン駆動設計 (Vaughn Vernon)
• 意訳Domain-Driven Design (@hirodoragon112 さん) ◦ 「単一モデルを介しての相互フィードバック」は、こちら の資料の議論を基としています
ご清聴ありがとうございました 36