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
170
アート、サイエンス、「わかりやすさ」 / art, science, "easy to understand"
tooppoo
1
20k
ソフトウェアと「動的平衡」 / software-and-dynamic-equilibrium
tooppoo
1
950
javascriptでも条件式を使いたい話 / want to use conditional expression in javascript
tooppoo
0
6.3k
Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component
tooppoo
4
3.5k
技術書・方法論とのお付き合い / how to learn theory
tooppoo
4
1.2k
「オブジェクト指向」を再考する / reconsider "object-oriented"
tooppoo
2
790
「モデル」の二面性と設計を考える / dual nature of "model"
tooppoo
2
1.7k
「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain
tooppoo
9
2.7k
Other Decks in Programming
See All in Programming
AIエージェントを活用したアプリ開発手法の模索
kumamotone
1
750
SLI/SLOの設定を進めるその前に アラート品質の改善に取り組んだ話
tanden
2
730
SQL Server ベクトル検索
odashinsuke
0
120
OUPC2024 Day 1 解説
kowerkoint
0
400
ベクトル検索システムの気持ち
monochromegane
30
8.9k
いまさら聞けない生成AI入門: 「生成AIを高速キャッチアップ」
soh9834
12
3.7k
本当だってば!俺もTRICK 2022に入賞してたんだってば!
jinroq
0
250
GDG Super.init(version=6) - From Where to Wear : 모바일 개발자가 워치에서 발견한 인사이트
haeti2
0
560
新卒から4年間、20年もののWebサービスと 向き合って学んだソフトウェア考古学
oguri
8
6.7k
RCPと宣言型ポリシーについてのお話し
kokitamura
2
150
CTFのWebにおける⾼難易度問題について
hamayanhamayan
1
980
令和トラベルにおけるコンテンツ生成AIアプリケーション開発の実践
ippo012
1
260
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
336
57k
How to train your dragon (web standard)
notwaldorf
91
5.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
500
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
How STYLIGHT went responsive
nonsquared
99
5.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
700
Mobile First: as difficult as doing things right
swwweet
223
9.5k
4 Signs Your Business is Dying
shpigford
183
22k
How GitHub (no longer) Works
holman
314
140k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
102
18k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Building Your Own Lightsaber
phodgson
104
6.3k
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