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.3k
何が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
130
アート、サイエンス、「わかりやすさ」 / art, science, "easy to understand"
tooppoo
1
19k
ソフトウェアと「動的平衡」 / software-and-dynamic-equilibrium
tooppoo
1
750
javascriptでも条件式を使いたい話 / want to use conditional expression in javascript
tooppoo
0
5.8k
Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component
tooppoo
4
3.1k
技術書・方法論とのお付き合い / how to learn theory
tooppoo
4
1k
「オブジェクト指向」を再考する / reconsider "object-oriented"
tooppoo
2
640
「モデル」の二面性と設計を考える / dual nature of "model"
tooppoo
2
1.5k
「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain
tooppoo
9
2.4k
Other Decks in Programming
See All in Programming
Java 22 Overview
kishida
1
180
⼤規模⾔語モデルの拡張(RAG)が 終わったかも知れない件について
nearme_tech
23
15k
FigmaとPHPで作る1ミリたりとも表示崩れしない最強の帳票印刷ソリューション
ttskch
43
19k
1BRC--Nerd Sniping the Java Community
gunnarmorling
0
340
try!Swift Tokyo 2024 参加報告 LT
akidon0000
1
220
PHP8.3の機能を振り返る / Review of PHP 8.3 features
seike460
PRO
1
110
Git Lint
bkuhlmann
4
750
try! Swift Tokyo 初参加報告LT
hinakko2
0
220
Scalable Customer Journey Orchestration (CJO)
lewuathe
0
310
educure_カリキュラム生操作マニュアル.pdf
linew_official
0
790
Apache Hive 4 on Treasure Data
ryukobayashi
0
310
StoreKit2によるiOSのアプリ内課金のリニューアル
kangnux
0
110
Featured
See All Featured
Thoughts on Productivity
jonyablonski
58
3.8k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Imperfection Machines: The Place of Print at Facebook
scottboms
260
12k
Side Projects
sachag
451
41k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Creatively Recalculating Your Daily Design Routine
revolveconf
210
11k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
The Cost Of JavaScript in 2023
addyosmani
16
3.9k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
40
4.4k
Designing the Hi-DPI Web
ddemaree
276
33k
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