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
360
DDDとは結局何なのか
200718 Zli x DMM 合同LT
acomagu
July 18, 2020
Tweet
Share
More Decks by acomagu
See All by acomagu
Stripe SSoT をするべきか否か
acomagu
0
52
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
98
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
0
96
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
320
Stripe リコンサイルの勘所
acomagu
0
490
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.2k
AWS CDK を支える Constructs について
acomagu
0
170
API Gateway HTTP API について
acomagu
0
140
JP_Stripes: 一貫性に寄与する設計
acomagu
0
97
Other Decks in Technology
See All in Technology
オブザーバビリティが育むシステム理解と好奇心
maruloop
3
1.6k
OTEPsで知るOpenTelemetryの未来 / Observability Conference Tokyo 2025
arthur1
0
330
AWSが好きすぎて、41歳でエンジニアになり、AAIを経由してAWSパートナー企業に入った話
yama3133
2
190
進化する大規模言語モデル評価: Swallowプロジェクトにおける実践と知見
chokkan
PRO
1
210
プレイドのユニークな技術とインターンのリアル
plaidtech
PRO
1
520
現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ / Beyond the Field Barriers: Instrumentation Injection and the Future of Observability
aoto
PRO
1
700
ざっくり学ぶ 『エンジニアリングリーダー 技術組織を育てるリーダーシップと セルフマネジメント』 / 50 minute Engineering Leader
iwashi86
6
3.5k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
14
82k
SREのキャリアから経営に近づく - Enterprise Risk Managementを基に -
shonansurvivors
1
420
CLIPでマルチモーダル画像検索 →とても良い
wm3
1
630
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
240
会社を支える Pythonという言語戦略 ~なぜPythonを主要言語にしているのか?~
curekoshimizu
4
910
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
How to Think Like a Performance Engineer
csswizardry
27
2.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Scaling GitHub
holman
463
140k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Facilitating Awesome Meetings
lara
57
6.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Six Lessons from altMBA
skipperchong
29
4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
The Cost Of JavaScript in 2023
addyosmani
55
9.1k
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 で重視していることをしっかりと把握し、詳細に気を 取られすぎないことが大切
ありがとうございました!!