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とは結局何なのか
Search
acomagu
July 18, 2020
Technology
460
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
DDDとは結局何なのか
200718 Zli x DMM 合同LT
acomagu
July 18, 2020
More Decks by acomagu
See All by acomagu
サーバーレスから Durable Execution へ
acomagu
0
19
Payment Records API を使って地域通貨を Stripe Dashboard に統合してみた
acomagu
0
67
Restate x Stripe: 安心して眠れる決済システムを目指して
acomagu
0
18
Stripe SSoT をするべきか否か
acomagu
0
86
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
130
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
180
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
660
Stripe リコンサイルの勘所
acomagu
0
540
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.3k
Other Decks in Technology
See All in Technology
AIエージェントを前提としたプラットフォーム エンジニアリング:GKEで作るAgent-Ready Golden Path
legalontechnologies
PRO
2
220
【CEDEC2026】グラフィックスエンジニアのためのニューラルシェーディング入門
cygames
PRO
0
130
FPGAが実現する遠方宇宙の高空間分解能天体撮影 -大型地上望遠鏡の視力を補正する「補償光学」とは?-
komei_mt
0
210
侵入は突然に 〜 IoTマルウェアと悪用される家庭の機器 ~ / When Intrusion Strikes: IoT Malware and the Abuse of Home Devices
nttcom
0
1.6k
ラジオの科学
frievea
0
290
【CEDEC2026】『Relink』を拡張せよ - 『GRANBLUE FANTASY: Relink - Endless Ragnarok』の開発速度と品質を守るCI運用
cygames
PRO
0
150
DatadogのBits Chatが開発組織にもたらしたもの / What Bits Chat Has Brought Us
sms_tech
1
180
Master Dataグループ紹介資料
sansan33
PRO
1
4.8k
Eight Engineering Unit 紹介資料
sansan33
PRO
3
8.2k
第3回しろおびセキュリティスポンサーセッション
log0417
0
160
MIRU 2026 チュートリアル
keisuke198619
0
880
Issue設計から始める仕様駆動開発 / 20260731 Mizuki Hirata
shift_evolve
PRO
1
150
Featured
See All Featured
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
590
Designing Powerful Visuals for Engaging Learning
tmiket
1
480
How Software Deployment tools have changed in the past 20 years
geshan
1
34k
The Curious Case for Waylosing
cassininazir
1
450
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
73
41k
Utilizing Notion as your number one productivity tool
mfonobong
4
530
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
380
Producing Creativity
orderedlist
PRO
348
40k
For a Future-Friendly Web
brad_frost
183
10k
Mind Mapping
helmedeiros
PRO
1
300
Un-Boring Meetings
codingconduct
0
380
Transcript
DDDとは結局何なのか @acomagu 200718 Zli x DMM合同LT会
今回の目的 DDD 本に載っていることを整理し、DDD の全体像を改めて見てみる DDD が言っていることと言っていないことを整理し、ありがちなクックブックから開放され る
DDD とは何か
DDD って何? - ドメインエキスパートとドメインモデルを議論すること? - Entity/Value Object? - リポジトリ/ファクトリ? -
ビジネスロジックを分けること? - コンテキストを分けること? - ユビキタス言語?
DDD って何? - ドメインエキスパートとドメインモデルを議論すること? - Entity/Value Object? - リポジトリ/ファクトリ? -
ビジネスロジックを分けること? - コンテキストを分けること? - ユビキタス言語? DDD 本にはめちゃめちゃいろいろ書いてある→
DDD って何? DDD本 序文 「先進的なソフトウェア設計者は、少なくともここ20年の間、ドメインモデリングと設計が 重大なテーマであると認識してきた。しかし、何をする必要があって、それをどのように すべきかについては、驚くほどわずかしか書かれていない。だが、明確に体系化されて はいないものの、オブジェクトコミュニティの底流として、ある哲学が出現してきている。 私はその哲学を、ドメイン駆動設計と呼んでいる。」
DDD って何? DDD本 序文 「先進的なソフトウェア設計者は、少なくともここ20年の間、ドメインモデリングと設計が 重大なテーマであると認識してきた。しかし、何をする必要があって、それをどのように すべきかについては、驚くほどわずかしか書かれていない。だが、明確に体系化されて はいないものの、オブジェクトコミュニティの底流として、ある哲学が出現してきている。 私はその哲学を、ドメイン駆動設計と呼んでいる。」 (よくわからない)
特定の手順や方法ではなさそう
DDD って何? Domain-Driven Design Reference より - コアドメインに集中する - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
- 境界付けられたコンテキストの中のユビキタス言語で話す
DDD って何? “Tackling Complexity in the Heart of Software” by
Eric Evans(DDD Europe 2016) より - ドメインの中核となる複雑さと機会に焦点を当てる - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する - 明示的にそれらのモデルを表現するソフトウェアを書く - 境界付けられたコンテキストの中のユビキタス言語で話す
DDD って何? Explore DDD 2018 “DDD Isn't Done: A Skeptical,
Optimistic , Pragmatic Look” より
DDD って何? Explore DDD 2018 “DDD Isn't Done: A Skeptical,
Optimistic , Pragmatic Look” より DDD はクックブックではない
DDD って何? Explore DDD 2018 “DDD Isn't Done: A Skeptical,
Optimistic , Pragmatic Look” より DDD は原則だ!
これこそが DDD “Tackling Complexity in the Heart of Software” by
Eric Evans(DDD Europe 2016) より - ドメインの中核となる複雑さと機会に焦点を当てる - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する - 明示的にそれらのモデルを表現するソフトウェアを書く - 境界付けられたコンテキストの中のユビキタス言語で話す
DDD 本の中に書いてあることって...?
DDD 本の中に書いてあることって? - ドメインエキスパートとドメインモデルを議論すること? - Entity/Value Object? - リポジトリ/ファクトリ? -
ビジネスロジックを分けること? - コンテキストを分けること? - ユビキタス言語? ↑これらは何なのか?
Domain-Driven Design Reference: Pattern Language Overview(vii ページ)より
Domain-Driven Design Reference: Pattern Language Overview(vii ページ)より
DDD 本の中でキーとなる用語 - モデル駆動設計 - ユビキタス言語 - 境界づけられたコンテキスト これらと「DDD の原則」を見比べていこう
モデル駆動開発 関連: E/VO、集約、オブジェクトのライフサイクル(、ドメインエキスパート) 原則: - “ドメインの中核となる複雑さと機会に焦点を当てる” - “ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する” - “明示的にそれらのモデルを表現するソフトウェアを書く”
DDD の中心となる考え方 モデルをドメインエキスパートと協業して作り上げ、それを表現するソフトウェアを書く。更に ドメイン領域を他の部分と分ける。 また、オブジェクトのライフサイクルと集約に関するパターンを含む
モデル駆動設計 所感 - もともとオブジェクト指向では、現実世界の物をヒントにモデリングをするというアイ ディアは一般的だった - 「業務内容の名詞をクラス名にする」とか聞いたことあるはず - DDD ではソフトウェア設計のなかでもドメインエキスパートと議論すべき部分を明確
にした
ユビキタス言語 関連: 境界づけられたコンテキスト、モデル駆動設計 原則: - “境界付けられたコンテキストの中のユビキタス言語で話す” チーム内(ドメインエキスパート含む)のコミュニケーションや、ソフトウェア内で必ず同じ 用語を使うということ ドメインエキスパートと開発者や、開発者同士の認識のずれを防ぐ モデルの進化はユビキタス言語の進化である
ユビキタス言語 所感 IDDD「Evans がソフトウェア開発コミュニティにもたらした『発明』をひとつあげるとすれ ば、それはユビキタス言語だ」 シンプルなアイディアだけど強力ですよね
境界づけられたコンテキスト 関連: コンテキスト間の関係、ユビキタス言語 原則: - “境界付けられたコンテキストの中のユビキタス言語で話す” いろいろな理由で分けられるモデルの境界 チームやステークホルダーの境界であり、言語の境界である。解決領域寄りの概念なの で(IDDD「境界づけられたコンテキストは特定のソリューションを表す」)、このコンテキス トがどの課題(ドメイン)に向けたものなのかを考えることが重要。
境界づけられたコンテキスト 所感 - IDDD「コンテキストは DDD の王様」 - 技術的な境界が必ずしもコンテキストを分けるわけではない(IDDD 2.4章)。しかし チームの境界はコンテキストを分ける。
- ユビキタス言語が重なったと言う理由だけでコンテキストを分けるのは早計だと思 います。既存のモデル内で複数のオブジェクトに分けるだけで解決できることもあり ます。 - コンテキストを分けるとデータの共有に課題が生じることが多いです(データベース の共有や非同期コミュニケーションが必要になる場合がある)。 - 例えば一般的にサーバーとフロントエンドは別のコンテキストと言えますし、外部ラ イブラリや外部サービスも別コンテキストと考えられます。
DDD まわりまとめ - モデル駆動開発 - ユビキタス言語 - 境界づけられたコンテキスト ↑これらが DDD
の原則を支える基本要素であり、より具体的な方法やパターンも含んで いる。
DDD が重視していないこと
DDD が重視していないこと 具体的なことはだいたい全部 - クリーンアーキテクチャ/ヘキサゴナルアーキテクチャ - ドメイン層は純粋関数にしなければならない - リポジトリはユースケース層のみで使う -
1つのマイクロサービスは1つのコンテキストにあたる - コンテキスト間の通信はユースケース層をまたがなければならない - 外部との通信はすべてリポジトリを通すべき ↑が間違いではないが、なぜそうするのかをしっかり理由づけするのが大切(でないと 後々自分で自分の首を絞めることになる)
おわりに
(最近の)感想 - DDD とはほぼ概念であり、いろいろな抽象的な思想や幅広い手法を含むので、何 を指すかわからないのでDDD という言葉単体では使わないほうがよさそう - 適切なモデリングをするためにはオブジェクト指向の経験が必須で、DDD を始める 前にオブジェクト指向でちゃんと設計したプログラムを作る練習がまず必要だなと
最近痛感している
まとめ DDD とは以下の4つの原則にまとめられる - ドメインの中核となる複雑さと機会に焦点を当てる - ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する - 明示的にそれらのモデルを表現するソフトウェアを書く -
境界付けられたコンテキストの中のユビキタス言語で話す 上記の原則を支える概念は以下の3つにまとめられる - モデル駆動開発 - ユビキタス言語 - 境界づけられたコンテキスト
まとめ DDD を実践するなら、DDD で重視していることをしっかりと把握し、詳細に気を 取られすぎないことが大切
ありがとうございました!!