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
レバレジーズTechアカウント
June 30, 2023
Technology
0
3.8k
レイヤードアーキテクチャ(改) とDDD
レイヤードアーキテクチャ(改) とDDD
レバレジーズTechアカウント
June 30, 2023
Tweet
Share
More Decks by レバレジーズTechアカウント
See All by レバレジーズTechアカウント
Step by Stepで学ぶ、ADT(代数的データ型)、モナドからEffect-TSまで
leveragestech
1
3.1k
TypescriptでのContextualな構造化ロギングと社内全体への導入
leveragestech
3
590
デザインシステム基盤構築実践
leveragestech
1
2.4k
荒廃したテックブログの再生_技術広報LT大会
leveragestech
5
5.6k
文系大学生と学び考える開発生産性
leveragestech
1
28
「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」で読み解くレバテックのこれまでとこれから
leveragestech
0
58
社内共通ルールを値オブジェクトにして社内ライブラリとして運用してみた話
leveragestech
7
3.1k
Effect-TSを利用した副作用を分離する設計について
leveragestech
0
1.3k
マネジメント未経験の脳筋が開発チームのリーダーになって感じた苦悩と学び
leveragestech
0
91
Other Decks in Technology
See All in Technology
cgroup v2 で何が変わったのか / TechFeed Experts Night #28
tenforward
2
160
Dungeons and Dragons and Rails
joelq
0
230
生成AIと産業向けソフトウェアの自動生成 〜 ハノーバーメッセ2024より〜
kioto
2
430
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
37k
Real World Type Puzzle and Code Generation
yukukotani
4
640
生成AIがもたらす変革 / GitHubGalaxy_CyberAgent
cyberagentdevelopers
PRO
2
110
技術力の伸ばし方を考える
khirata
0
140
The depthes of profiling Ruby - RubyKaigi 2024
osyoyu
0
160
日本が誇るイタリアのダンスミュージック!? ユーロビートって何??
minorun365
PRO
2
220
.NET GraphQL Client のリアル
sansantech
PRO
1
310
Domain-driven Design: A Complete Example
ewolff
2
260
生成AI活用推進の為にやったこと/やらなかったこと
ktc_wada
0
180
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
Making Projects Easy
brettharned
109
5.5k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
How GitHub (no longer) Works
holman
305
140k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
How to Ace a Technical Interview
jacobian
273
22k
Building a Scalable Design System with Sketch
lauravandoore
457
32k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
Transcript
レイヤードアーキテクチャ (とDDD) テックフェス2023春 松浪 亮
Profile 松浪 亮(まつなみ りょう) Matsunami Ryo 出⾝:⼤阪府 ⼊社:2022/01 所属:レバテックID開発チーム 最近のお気に⼊り
今回お話しする内容は... レイヤードアーキテクチャ
10か⽉くらい前にも話してたけど... ※ アーキテクチャスキルアッププロジェクト
発表して半年経ってから いちゃもん コメントが...
要約すると、 「内容薄いからもっと詳しく書け」 発表して半年経ってから いちゃもん コメントが...
レイヤードアーキテクチャ(改) (とDDD) テックフェス2023春 松浪 亮
今回お話しする内容は... [1] レイヤードアーキテクチャについて、おさらい
今回お話しする内容は... [1] レイヤードアーキテクチャについて、おさらい [2] コードを元にレイヤードアーキテクチャを解説
今回お話しする内容は... [1] レイヤードアーキテクチャについて、おさらい [2] コードを元にレイヤードアーキテクチャを解説 [3] DI(依存性の注⼊)でコードをドメイン中⼼に作り変える
⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
レイヤードアーキテクチャ エリック・エヴァンスのドメイン駆動設計(翔泳社)
4つのレイヤーに分けてモジュールを配置 ▪Infrastructure層 データストアへの永続化や外部APIとの通信など技術 的な機能を実装する ▪Domain層 ドメイン(ソフトウェアで解決したい対象領域のこ と)モデルのルール/制約を実装する ▪Application層 ドメイン層を組み合わせてユースケースを実装する ▪Presentation層
UIやユニットテストなど、アプリケーション(ユース ケース)層を呼び出すコードを実装する
ルールは1つだけ エリック・エヴァンスのドメイン駆動設計(翔泳社) 依存OK 依存NG
依存関係について 依存する側 依存される側 依存⽅向
依存関係について 依存する側 依存される側 依存⽅向 変更 依存関係について
依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 依存関係について
依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更 依存関係について
依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更 影響なし 依存関係について
依存関係について 依存する側は影響を与えないので改修・変更が容易になり、 依存される側は変更の影響を受けないので依存する側よりも安定する。 依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更
影響なし
依存関係について 変更頻度が⾼い機能は依存する側(上位の層)に、 変更の影響を受けたくない機能は依存される側(下位の層)に設計すべき。 依存する側は影響を与えないので改修・変更が容易になり、 依存される側は変更の影響を受けないので依存する側よりも安定する。 依存関係について 依存する側 依存される側 依存⽅向 変更
影響あり 変更 影響なし
レイヤードアーキテクチャの問題点 エリック・エヴァンスのドメイン駆動設計(翔泳社) DomainがInfrastructureに依存してよいことになっている → 変更の影響を受けたくないはずのDomainが依存する側にある
レイヤードアーキテクチャの問題点2 エリック・エヴァンスのドメイン駆動設計(翔泳社) 理論上はPresentationもInfrastructureに依存してよい → Presentationからデータを更新できてしまう
ドメインルールがDomain層から漏れ出てしまう エリック・エヴァンスのドメイン駆動設計(翔泳社) 理論上はPresentationもInfrastructureに依存してよい → Presentationからデータを更新できてしまう → 本来、Domainにあるべき実装を Presentationに実装できてしまう ドメイン
ロジック
全体を⾒ないと仕様を把握できなくなる エリック・エヴァンスのドメイン駆動設計(翔泳社) 理論上はPresentationもInfrastructureに依存してよい → Presentationからデータを更新できてしまう → 本来、Domainにあるべき実装を Presentationに実装できてしまう →
修正箇所が分散する → 達成したいことは全体を⾒ないとわからない ドメイン ロジック ドメイン ロジック
解決策 エリック・エヴァンスのドメイン駆動設計(翔泳社) Infrastructureからの依存の向きを変える → 依存性を逆転させる
つまり... ドメイン駆動設計 モデリング/実装ガイド(松岡 幸一郎さん:著) ドメインを中⼼に置く → ドメイン駆動設計
つまり... ドメイン駆動設計 モデリング/実装ガイド(松岡 幸一郎さん:著) 詳しくは...
⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
例(コードサンプル) • ユーザ情報を登録する超シンプルなWebアプリケーションを想定 ◦ ⼊⼒として、name(⽒名)とemail(メールアドレス)を受け取る ◦ バリデーションチェックを実施する ◦ バリデーションに問題なければRDBに登録する •
レイヤードアーキテクチャに則って実装してみる ◦ Presentation層 ▪ → Application層 • → Domain層 ◦ → Infrastructure層
Presentation層
Presentation層 Presentation層
Presentation層 Presentation層
Application層
Application層
Application層
Domain層
Domain層 新規ユーザを⽣成時のドメイン知識(ルール/制約)を実装 →バリデーションチェックや初期設定など →常に正しいインスタンスしか存在させなくする
Infrastructure層
結果... EndPoint("/users/create") UseCase Entity Repository
⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
ドメインを中⼼にするには... EndPoint("/users/create") UseCase Entity Repository ← Repositoryを...
EndPoint("/users/create") UseCase Repository Repository Entity ↑ DI(依存性の注⼊)する こうする...!!
こうする...?? EndPoint("/users/create") UseCase Repository Repository Entity ↑ DI(依存性の注⼊)する
DI(依存性の注⼊)とは 依存性の注⼊(いぞんせいのちゅうにゅう、英: Dependency injection)とは、あるオブジェ クトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。 DIは制御の反転の⼀種で、オブジェクトの作成と利⽤について関⼼の分離を⾏い、疎結合な プログラムを実現することを⽬的としている。 by Wikipedia
DI(依存性の注⼊)とは?? 依存性の注⼊(いぞんせいのちゅうにゅう、英: Dependency injection)とは、あるオブジェ クトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。 DIは制御の反転の⼀種で、オブジェクトの作成と利⽤について関⼼の分離を⾏い、疎結合な プログラムを実現することを⽬的としている。 by Wikipedia
Presentation層
Presentation層
Presentation層
Application層
ドメインを中⼼にするために... ・Repositoryのインタフェースを⽤意する ・Infrastructureの実態をコンストラクタで渡す
ドメインを中⼼にするために... ・Repositoryのインタフェースを⽤意する ・Infrastructureの実態をコンストラクタで渡す → DI(依存性の注⼊)
Application層
Application層 Applicationからインタフェースを参照(依存)する形に なった → Repositoryのコードの詳細が⾒えなくなった → Infrastructureの実装に依存しなくなった!
Q.依存しなくなると何が嬉しいのか?
Q.依存しなくなると何が嬉しいのか? A.ユニットテストしやすくなる Q.依存しなくなると何が嬉しいのか?
ユニットテストでモックに差し替える ①インタフェースを実装したMockを⽤意する → 適当な値を返す ③RDBに接続しないでユニットテストができる ②コンストラクタでMockを渡す
例外のパターンもテストしやすい ①インタフェースを実装したMockを⽤意する → 例外を返す ③例外のパターンもユニットテストができる ②コンストラクタでMockを渡す
⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
まとめ • レイヤードアーキテクチャは下記の概念に沿って設計する ◦ 4つのレイヤーで責務を分割する ◦ 常に上位から下位の⽅向に依存させる • ⽋点としてInfrastructure層に依存する設計となる ◦
依存関係を逆転させるためにDI(依存性の注⼊)を利⽤する ◦ DIによってドメインを中⼼とした設計にすることができる ▪ オニオンアーキテクチャが実現できる • Infrastructure層に依存させないことでテストしやすくなる ◦ Infrastructure層のコードの実態をMockに差し替えやすい
ご清聴ありがとうございました