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.4k
何が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
150
アート、サイエンス、「わかりやすさ」 / art, science, "easy to understand"
tooppoo
1
20k
ソフトウェアと「動的平衡」 / software-and-dynamic-equilibrium
tooppoo
1
840
javascriptでも条件式を使いたい話 / want to use conditional expression in javascript
tooppoo
0
6.1k
Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component
tooppoo
4
3.3k
技術書・方法論とのお付き合い / how to learn theory
tooppoo
4
1.1k
「オブジェクト指向」を再考する / reconsider "object-oriented"
tooppoo
2
740
「モデル」の二面性と設計を考える / dual nature of "model"
tooppoo
2
1.6k
「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain
tooppoo
9
2.6k
Other Decks in Programming
See All in Programming
Kotlin Multiplatform at Stable and Beyond (Kotlin Vienna, October 2024)
zsmb
2
410
今日で分かる!カスタムコップの作り方
krpk1900
2
150
いかにして不足・不整合なくデータ移行したか
tjmtmmnk
1
680
4年間変わらなかった YOUTRUSTのアーキテクチャ
daiki1003
2
670
tsconfig.jsonの最近の新機能 ファイルパス編
uhyo
7
1.9k
C#および.NETに対する誤解をひも解く
ymd65536
0
330
LangChain & LangServeでAPIを爆速作成
kijitorabuti
2
350
Debugging: A Few Things You Should Know
jmatsu
1
130
Jakarta EE as Seen Trough the Lens of the ASF
ivargrimstad
0
760
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
240
実践サーバーレスパフォーマンスチューニング ~その実力に迫る~ / Practical Serverless Performance Tuning ~A Close Look at its Power~
seike460
PRO
2
230
Cloud Adoption Framework にみる組織とクラウド導入戦略
tomokusaba
2
670
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
325
23k
Happy Clients
brianwarren
97
6.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
13
1.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
362
19k
Statistics for Hackers
jakevdp
796
220k
Faster Mobile Websites
deanohume
304
30k
Embracing the Ebb and Flow
colly
84
4.4k
Docker and Python
trallard
40
3k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2k
Visualization
eitanlees
143
15k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
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