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
快速入門可觀測性
blueswen
0
500
テストコード書いてみませんか?
onopon
2
350
非ブラウザランタイムとWeb標準 / Non-Browser Runtimes and Web Standards
petamoriken
0
430
php-conference-japan-2024
tasuku43
0
440
ASP.NET Core の OpenAPIサポート
h455h1
0
130
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
110
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
220
『改訂新版 良いコード/悪いコードで学ぶ設計入門』活用方法−爆速でスキルアップする!効果的な学習アプローチ / effective-learning-of-good-code
minodriven
28
4.4k
ISUCON14感想戦で85万点まで頑張ってみた
ponyo877
1
720
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
1.4k
Fixstars高速化コンテスト2024準優勝解法
eijirou
0
190
DMMオンラインサロンアプリのSwift化
hayatan
0
200
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Cost Of JavaScript in 2023
addyosmani
46
7.2k
Typedesign – Prime Four
hannesfritz
40
2.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
192
16k
Embracing the Ebb and Flow
colly
84
4.5k
Music & Morning Musume
bryan
46
6.3k
BBQ
matthewcrist
85
9.4k
Docker and Python
trallard
43
3.2k
The Cult of Friendly URLs
andyhume
78
6.1k
A Modern Web Designer's Workflow
chriscoyier
693
190k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Side Projects
sachag
452
42k
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