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
180
DDDとは結局何なのか
200718 Zli x DMM 合同LT
acomagu
July 18, 2020
Tweet
Share
More Decks by acomagu
See All by acomagu
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
32
Stripe リコンサイルの勘所
acomagu
0
150
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
1.7k
AWS CDK を支える Constructs について
acomagu
0
120
API Gateway HTTP API について
acomagu
0
97
JP_Stripes: 一貫性に寄与する設計
acomagu
0
71
Stripeではじめての決済
acomagu
0
660
あなたの知らない(かもしれない)Git
acomagu
2
95
UTF-8 依存の Go コードとは?
acomagu
1
140
Other Decks in Technology
See All in Technology
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
210
GrafanaMeetup_AmazonManagedGrafanaのアクセス制御機能とマルチテナント環境下でのアクセス制御について
daitak
0
230
一生覚えておきたい「システム開発=コミュニケーション」〜初めての実務案件振り返りLT〜
maimyyym
0
140
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.8k
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
1
520
Terraformあれやこれ/terraform-this-and-that
emiki
8
1.4k
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
620
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
IaCジェネレーターとBedrockで詳細設計書を生成してみた
tsukasa_ishimaru
1
190
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
5
520
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
0
2.7k
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
3
2.5k
Featured
See All Featured
The Invisible Customer
myddelton
114
12k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
16
2.6k
Building Applications with DynamoDB
mza
88
5.6k
Visualization
eitanlees
136
14k
A designer walks into a library…
pauljervisheath
200
23k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
20
1.9k
No one is an island. Learnings from fostering a developers community.
thoeni
16
2.1k
What the flash - Photography Introduction
edds
64
11k
The MySQL Ecosystem @ GitHub 2015
samlambert
243
12k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
116
18k
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 で重視していることをしっかりと把握し、詳細に気を 取られすぎないことが大切
ありがとうございました!!