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
0
300
DDDとは結局何なのか
200718 Zli x DMM 合同LT
acomagu
July 18, 2020
Tweet
Share
More Decks by acomagu
See All by acomagu
Stripe SSoT をするべきか否か
acomagu
0
46
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
82
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
78
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
260
Stripe リコンサイルの勘所
acomagu
0
450
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.1k
AWS CDK を支える Constructs について
acomagu
0
170
API Gateway HTTP API について
acomagu
0
140
JP_Stripes: 一貫性に寄与する設計
acomagu
0
94
Other Decks in Technology
See All in Technology
成立するElixirの再束縛(再代入)可という選択
kubell_hr
0
280
CI/CDとタスク共有で加速するVibe Coding
tnbe21
0
180
TODAY 看世界(?) 是我們在看扣啦!
line_developers_tw
PRO
0
200
OCI Oracle Database Services新機能アップデート(2025/03-2025/05)
oracle4engineer
PRO
1
150
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
260
「実体」で築く共通認識: 開発現場のコミュニケーション最適化 / Let's Get on the Same Page with Concrete Artifacts: Optimization of Communication in dev teams
kazizi55
0
140
「どこにある?」の解決。生成AI(RAG)で効率化するガバメントクラウド運用
toru_kubota
2
430
活きてなかったデータを活かしてみた話 / Shirokane Kougyou vol 19
sansan_randd
1
340
エンジニア採用から始まる技術広報と組織づくり/202506lt
nishiuma
8
1.7k
脅威をモデリングしてMCPのセキュリティ対策を考えよう
flatt_security
4
1.7k
OpenTelemetry Collector internals
ymotongpoo
5
550
原則から考える保守しやすいComposable関数設計
moriatsushi
3
430
Featured
See All Featured
Code Review Best Practice
trishagee
68
18k
The Invisible Side of Design
smashingmag
299
51k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
How STYLIGHT went responsive
nonsquared
100
5.6k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Music & Morning Musume
bryan
46
6.6k
How GitHub (no longer) Works
holman
314
140k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Site-Speed That Sticks
csswizardry
10
640
Optimizing for Happiness
mojombo
379
70k
Documentation Writing (for coders)
carmenintech
71
4.9k
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 で重視していることをしっかりと把握し、詳細に気を 取られすぎないことが大切
ありがとうございました!!