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
趣味ではじめる ドメイン駆動設計+クリーンアーキテクチャ
Search
AokabiC
July 17, 2021
Programming
2
750
趣味ではじめる ドメイン駆動設計+クリーンアーキテクチャ
23卒エンジニア志望学生LT会 vol.2 登壇資料
https://connpass.com/event/215902/
AokabiC
July 17, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
Fixstars高速化コンテスト2024準優勝解法
eijirou
0
200
“あなた” の開発を支援する AI エージェント Bedrock Engineer / introducing-bedrock-engineer
gawa
10
1.4k
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
270
個人アプリを2年ぶりにアプデしたから褒めて / I just updated my personal app, praise me!
lovee
0
300
GitHub CopilotでTypeScriptの コード生成するワザップ
starfish719
28
6.1k
HTML/CSS超絶浅い説明
yuki0329
0
210
自分ひとりから始められる生産性向上の取り組み #でぃーぷらすオオサカ
irof
8
2.2k
BEエンジニアがFEの業務をできるようになるまでにやったこと
yoshida_ryushin
0
260
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
1
530
Vue.jsでiOSアプリを作る方法
hal_spidernight
0
120
知られざるDMMデータエンジニアの生態 〜かつてツチノコと呼ばれし者〜
takaha4k
3
1k
React 19でお手軽にCSS-in-JSを自作する
yukukotani
5
600
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
6
220
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Code Review Best Practice
trishagee
65
17k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
How STYLIGHT went responsive
nonsquared
96
5.3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Designing for Performance
lara
604
68k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
How to train your dragon (web standard)
notwaldorf
89
5.8k
Transcript
趣味ではじめる ドメイン駆動設計 +クリーンアーキテクチャ 碧黴(あおかび)@AokabiC
誰 • 碧黴(あおかび) • 東北大学大学院 情報科学研究科 M1 • 前世では競プロをやっていた •
最近はWeb Frontend (React) / Backend (Go, Python) • 絵を描く • GitHubとか: @AokabiC • Portfolio: team-seadrive.com 2
Agenda • 「ドメイン駆動設計」って? • ドメインモデルとは • Clean Architecture 各層ごとの役割に分けて説明 •
簡単なオブジェクト指向の知識を前提とします • コードはGolangですが、特有の知識は要求しません 3 by Renée French
「ドメイン駆動設計」って? • 「ドメイン」の知識を中心とした設計 • #とは • 難しそう? そうでもない • オブジェクト指向を最大限に生かすような設計
• 単一責任(責務の分離)、変更箇所は最小限 • 品質を担保しやすい • 「作って終わり」になりがちな趣味プロダクトを運用に導くヒント 4
ドメインとは • ソフトウェアが組み立てられる「世界」を記述したもの • 必要に応じて知識の取捨選択がされる • 現実世界でのトラック … エンジン動力で車輪が回転し走る •
輸送管理システムでのトラック … 荷物が一定量載る輸送手段でしかない • 現実 (or 仮想) の営みを必要十分に抽象化したもの(ドメインモデル) 物流拠点 輸送手段 輸送先 5
Twitter で考えてみる Tweet User ~ Twitter World ~ 6
Twitter で考えてみる 1:Many name username description Tweet User profile image
birth date text media created at ~ Twitter World ~ 7
Twitter で考えてみる 1:Many name username description Tweet User profile image
birth date text media created at ~ Twitter World ~ User 8 フォロー いいね リプライ …
Twitter で考えてみる • 概念、ルールがモデルとしてカプセル化されている(ドメインモデル) name username description User profile image
birth date - 13歳未満はNG - 正方形の jpeg / gif / png 画像 - … - 4~16文字の[a-zA-Z0-9_], 重複してはならない - … 9
ルールを持った値 • ルールを持った値: Value Object username - 4~16文字の[a-zA-Z0-9] 10
Value Object の特徴 • 不変 • 等価性によって比較される • 扱いとしてはリテラルやプリミティブ型に近い 等価性はドメインの性質によって決まる
== 11
User や Tweet は? • や は Value Object とは異なる性質がある
• ライフサイクルがある • User は生まれ、いつかは死んでいく • 等価性で比較されない • 姓名(=Userの属性)が同じでも、別人のはず • 識別子(ID)が要る → 同一性による比較 • 可変 • これらは Entity と呼ばれる User Tweet 12
• ライフサイクルのある値: Entity Entity 識別子 13
ドメイン層の責務 • Value Object や Entity を駆使して、 ソフトウェアが組み立てられる「世界」のルールを記述できる!* …しかし、これだけではルールを記述したのみ •
ソフトウェアとして使うためには それらを組み合わせて 機能を作らなければならない (ユースケース) * 実際にはこの他にも、Domain Service (VOやEntityの振る舞いとするには不自然なもの。Userの存在判定など) や Factory (複雑なEntityの生成方法を担う)などがドメイン層にある。今回は割愛。 14
ユースケース 1:Many name username description profile image birth date text
media created at User Tweet User フォロー いいね リプライ … ~ Twitter World ~ 15
• 機能として提供される営み • ドメインモデルを動かす • ドメインを組み合わせて記述するだけで、ソフトウェアは完成する? • Entity はライフサイクルがある… 永続化が必要
• ユースケースを使うための窓口が要る (例えば API なら endpoint を用意するよね) ユースケース 16
• 現実はそこまで甘くない • サービスとして提供するならサーバーを立てるし、 永続化をするには DB とかが要る • ユースケース層までの抽象的な記述と、DBなどの具象を繋ぐ必要がある →
アダプター 具象との橋渡し 17
インフラ層 DBと接続 サーバーを 立てる 18
インフラ層 DBと接続 サーバーを 立てる Controller: 変換器 サーバーとドメインとの 橋渡し(アダプター) 19
アダプター層 • 役割は「変換器」 20
アダプター層 • 役割は「変換器」 • Request, id が 不正な値なら弾く ( GET
users/:id ) 21
アダプター層 • 役割は「変換器」 • Request, id が 不正な値なら弾く ( GET
users/:id ) • ドメインでの処理結果を JSONに変換して返却 22
アダプター層 • 役割は「変換器」 • Request, id が 不正な値なら弾く ( GET
users/:id ) • ドメインでの処理結果を JSONに変換して返却 → ユースケースを APIとして提供できた! 23
永続化に伴う具象への依存 • 永続化まわりはドメインに書かざるを得ない → ドメインがDBなどの具象で汚染される • テスタビリティの低下、過大責務 (DBについてなにも知るべきでない) DBと接続して、Queryを実行して、… ドメイン
テスト用 mock 24
• どうすべきか? 永続化に伴う具象への依存 25
• どうすべきか? • 規格(I/F)を決めて守らせる • PC側は機器の実装詳細についてなにも知らない • 同じことを ドメイン –
DB 間でやる 永続化に伴う具象への依存 26
• ドメインに依存させる → 依存関係逆転の原則 (DIP) Repository による依存関係逆転 テスト用 mock ドメイン
27
• 実装はアダプター/インフラに置く • I/F を実装していれば、RDBだろうがmockだろうが好きに使える • 依存の中心は常にドメイン、具象からは I/F で守る →
Clean Architectureの重要な考え方 Repository による依存関係逆転 28
プター/インフラに置く ry による依存関係逆転 Clean Architecture User フォロー いいね リプライ …
変換 インフラ アダプ ター ユース ケース ドメイン モデル 抽象 具象 I/F 大事なのは ドメインと 実装詳細(具象)を 分けること 29
• 各層ごとに責務を分け、 依存をドメインに向かわせる → 責務ごとに単体テストが できる バグの特定を容易に / 品質担保 テスタビリティ
30 アダプターのテスト → Request / Responseの 体裁のみチェック
• 「作って終わり」になりがちな趣味プロダクトを運用に導くヒント 「ドメイン駆動設計」 → ドメイン中心で 思考 と コード を一致させる! まとめ
31
• 「作って終わり」になりがちな趣味プロダクトを運用に導くヒント 「ドメイン駆動設計」 → ドメイン中心で 思考 と コード を一致させる! →
高いテスタビリティと品質を担保する • コード量はMVCフレームワークに乗っかった場合と比べ増加する → とりあえず動かしたい場合は向かない (そもそも趣味プロダクトを完成まで持っていくのは難しい) まとめ 32
趣味ではじめる ドメイン駆動設計 +クリーンアーキテクチャ 碧黴(あおかび)@AokabiC
参考: - 成瀬 允宣 『ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本』 - The Clean
Architecture(翻訳) (https://blog.tai2.net/the_clean_architecture.html) - 【プログラミング】実践クリーンアーキテクチャ – YouTube (https://www.youtube.com/watch?v=BvzjpAe3d4g) - クリーンアーキテクチャ完全に理解した (https://gist.github.com/mpppk/609d592f25cab9312654b39f1b357c60) スライド内での実装(Golang): https://github.com/AokabiC/clean-like-api Appendix 34