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について勉強したので5分でまとめる
Search
y_ahiru
August 28, 2018
Programming
0
340
DDDについて勉強したので5分でまとめる
1ヶ月ほどDDDについて勉強したので、その成果を5分でLTしました。
y_ahiru
August 28, 2018
Tweet
Share
More Decks by y_ahiru
See All by y_ahiru
恣意性から考える、変更に強いモデルの作り方
yahiru
1
1k
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
10
2.5k
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
1k
フロントエンドエンジニアも知っておきたい HTTP/3 で変わること
yahiru
16
13k
ゆるふわCQRS入門
yahiru
2
690
設計におけるソリューションドメイン
yahiru
3
1.7k
PHPで始めるGitHub Actions
yahiru
1
800
5ヶ月でカバレッジを20%から90%にあげた話
yahiru
2
6.8k
入門ミューテーションテスト/ A bigginer's guide to Mutation testing
yahiru
0
1.5k
Other Decks in Programming
See All in Programming
フロントエンド開発に役立つクライアントプログラム共通のノウハウ / Universal client-side programming best practices for frontend development
nrslib
7
3.9k
エンジニアとして高みを目指す、 利益を生み出す設計の考え方 / design-for-profit
minodriven
23
12k
ИИ-Агенты в каждый дом – Алексей Порядин, PythoNN
sobolevn
0
150
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
1.7k
After go func(): Goroutines Through a Beginner’s Eye
97vaibhav
0
230
AIエージェント時代における TypeScriptスキーマ駆動開発の新たな役割
bicstone
4
1.5k
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
140
uniqueパッケージの内部実装を支えるweak pointerの話
magavel
0
910
Le côté obscur des IA génératives
pascallemerrer
0
120
複雑化したリポジトリをなんとかした話 pipenvからuvによるモノレポ構成への移行
satoshi256kbyte
1
760
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
ssssota
2
1.2k
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
0
380
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
890
Designing Experiences People Love
moore
142
24k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Music & Morning Musume
bryan
46
6.8k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
We Have a Design System, Now What?
morganepeng
53
7.8k
Transcript
DDDの勉強をしたので5分でまとめる
自己紹介 吉田です Twitter @strtyuu
ドメイン駆動設計とは? ドメインを モデリングして モデリングして モデリングし続ける設計手法のこと
ドメインとは? アプリケーションが解決したい問題そのもののこと
モデリングとは? モデルの振る舞いを定義していく作業のことを指します。
モデルとは? ドメインを構成する様々な要素のこと
たとえば 会議室の予約システムを作りますとなった場合 会議室はもちろんモデルになると思いますし 予約という概念もモデルになります。
モデリングのやり方 ドメインエキスパートとドメインについて話し合って 話し合いを設計に反映させて 設計を元に実装をして ドメインエキスパートとドメインについて話し合って 話し合いを設計に反映させて 設計を元に実装をして ドメインエキスパートと...
以下エンドレス
モデルがどんどん更新されてゆく 実装は更新されてゆくモデルについていかなければならない つまり、変更に対して柔軟な実装になっていないと、 ドメイン駆動設計っていうのは、実現できない
柔軟な実装をするために デザインパターンを駆使して、複雑さに立ち向かう Repository Entity ValueObject Layered Architecture Aggregate 他
レイヤードアーキテクチャ アプリケーションをいくつかの層に分けて それぞれの役割を明確に区別すること
レイヤー化するメリット 層同士の依存関係が最低限に抑えられるので 層のインターフェースが変わらなければ、他の層への影響はあまりない (ことが多い) つまり、変更がしやすくなる。
たとえば <?php class ApplicationLayer { public function reserve(Reservation $reservation) {
if ( ! $reservation->isReservable()) { // 予約不可な場合の処理 } // 登録処理 } } 予約が可能かどうかのロジックがいくら変わろうが、アプリケーション 層は変更せずにそのまま使用できる
基本的な4つの層 プレゼンテーション層 アプリケーション層 ドメイン層 インフラ層
プレゼンテーション層 アプリケーションの外側と内側の接点 最終的にアプリケーションの外側に渡したいデータを出力する役割を持 っている
アプリケーション層 ドメインロジック以外の処理を担当する
ドメイン層 ドメインのルール・ロジックを全て担当する。 ドメイン層以外はドメインロジックを持ってはいけない
インフラ層 データベースとのやりとりなどを担当する
ドメイン層を構成する要素 Domain Service Entity ValueObject Factory
ValueObject イミュータブル(不変)なオブジェクト 値としてあるべき姿や振る舞いを定義してあげる
たとえば 会議室の予約に通常の予約の他に「仮予約」や「キャンセル」などのス テータスがあった場合、予約のステータスの値には特定の値しか存在し てほしくありません。 そういったときなどにValueObjectを作ります。
Entity ミュータブル(可変)なオブジェクト 1つの1レコードをオブジェクト化するイメージ 複数のValueObjectやリレーション先のEntityなどで構成される 様々なドメインルールを表現する
たとえば キャンセルされた予約は予約済みに戻すことができないというドメイン ルールがあった場合、以下のような感じで表現出来ます <?php class Reservation { protected $status; function
reservedBy(User $user) { if ($this->status->isCancel()) { throw new LogicException(); } $this->user_id = $user->getUserId(); $this->status = new Status('Reserved'); } }
たとえば こういった書き方をすることによって、ドメインルールと矛盾した処理 をアプリケーション層で書くことが不可能になります <?php class ApplicationLayer { public function badReserve()
{ $canceledRsv = $this->rsv_repo->findById($id); $user = $this->user_repo->findById($user_id); // 絶対に例外が発生する $canceledRsv->reservedBy($user); $this->rsv_repo->save($reservation); } }
Factory Entityを生成する際に複雑な処理が必要な時などに使う
Domain Service Entity単体では対応しきれないドメインルールを担当する
たとえば ユーザーのメールアドレスは重複してはならないというドメインルール があった場合 これは複数のEntityに関わることなので1つのEntityだけでは判断しきれ ません。 そういった処理はDomain Serviceの仕事となります。
インフラ層を構成する要素 Aggregate Repository
Aggregate ライフサイクルが同じオブジェクトをひとまとめにする「概念」
たとえば 会議室の予約に、利用者一覧みたいなデータを登録できるとします。 利用者の人数は可変なので予約とは別テーブルにすることにします。 テーブルは別ですが、新規予約時に予約と一緒に利用者も登録されます し、予約の編集時に利用者も編集されますし、予約の削除時に利用者も 削除されるかと思います。 また、予約をどうこうする時以外は利用者のデータは変更されなさそう です。 こういった場合は予約と利用者は一つの集約と言えます。
Repository データベースへのアクセスを提供する役割を持つ。 Aggregateごとに作成して、整合性を保つ。 AggregateのルートになるEntity以外へは直接アクセスさせない。
たとえば 先ほどの例でいうと 予約がAggregateのルートになり、予約Entityからしか利用者のデータに は辿れなくします。 そうすることによって、Aggregate内の整合性を保ちやすくします。
たとえば ルートとなるReservationに利用者は10人までしか登録できないというド メインルールを定義します。 <?php class Reservation { protected $users =
[]; public function addUser(User $user) { if (count($this->users) > 10) { throw new LogicException(); } $this->users[] = $user; } }
たとえば そうすると、もちろんReservationEntityを使う限り10人を超えた利用者 は登録できなくなります <?php class ApplicationLayer { public function badAddUser()
{ // たくさんのユーザー $users = $this->user_repo->getAllUsers(); $reservation = $this->rsv_repo->findById($id); foreach ($users as $user) { // 10 人を越えると必ず例外が発生する $reservation->addUser($user); } $this->rsv_repo->save($reservation); } }
たとえば そして、RepositoryはルートEntityしか受け付けないようにすることで ドメインルールに適合したデータのみがDBへ書き込まれることが保証さ れます。 <?php class ReservationRepository { public function
save(Reservation $reservation) { // DB への書き込み処理 } }
まとめ デザインパターンを駆使して、変更が容易な設計にしよう! 変更を容易にしてモデリングをしまくろう! 良いアプリケーション、作ろうぜ!