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
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
ssssota
2
1.2k
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
140
Conquering Massive Traffic Spikes in Ruby Applications with Pitchfork
riseshia
0
150
Reduxモダナイズ 〜コードのモダン化を通して、将来のライブラリ移行に備える〜
pvcresin
2
690
プログラマのための作曲入門
cheebow
0
540
ABEMAモバイルアプリが Kotlin Multiplatformと歩んだ5年 ─ 導入と運用、成功と課題 / iOSDC 2025
akkyie
0
330
明日から始めるリファクタリング
ryounasso
0
120
メモリ不足との戦い〜大量データを扱うアプリでの実践例〜
kwzr
1
880
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
4
670
止められない医療アプリ、そっと Swift 6 へ
medley
1
120
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
920
複雑化したリポジトリをなんとかした話 pipenvからuvによるモノレポ構成への移行
satoshi256kbyte
1
790
Featured
See All Featured
Done Done
chrislema
185
16k
Six Lessons from altMBA
skipperchong
28
4k
Faster Mobile Websites
deanohume
310
31k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Unsuck your backbone
ammeep
671
58k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Designing for Performance
lara
610
69k
Code Reviewing Like a Champion
maltzj
525
40k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
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