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 Leverages
June 30, 2023
Technology
1
6.3k
レイヤードアーキテクチャ(改) とDDD
レイヤードアーキテクチャ(改) とDDD
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
840
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
69
ディメンショナルモデリングを軽く語る
leveragestech
1
3.2k
アクターモデルによる効率的な分散システム設計
leveragestech
0
3k
Terraform による運用効率化の取り組みと最新のテストアプローチの紹介
leveragestech
0
3k
OpenFGAで拓く次世代認可基盤 〜予告編〜
leveragestech
0
3k
リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力
leveragestech
0
3k
作ってわかる!非同期ランタイム
leveragestech
0
3k
レバテック開発部 技術広報 これまでとこれから
leveragestech
0
160
Other Decks in Technology
See All in Technology
MCP Clientを活用するための設計と実装上の工夫
yudai00
1
810
kintone開発組織のDevOpsへの移り変わりと実践
ueokande
1
120
ゴリラ.vim #36 ~ Vim x SNS ~ スポンサーセッション
yasunori0418
1
360
GoogleのAI Agent
shukob
0
140
オープンソースのハードウェアのコンテストに参加している話
iotengineer22
0
640
障害を回避するHttpClient再入門 / Avoiding Failures HttpClient Reintroduction
uskey512
1
140
データ戦略部門 紹介資料
sansan33
PRO
1
3.1k
KMP導⼊において、マネジャーとして考えた事
sansantech
PRO
1
210
Swiftは最高だよの話
yuukiw00w
2
290
Cursor Meetup Tokyo
iamshunta
2
660
Roo Codeにすべてを委ねるためのルール運用
pharma_x_tech
1
230
プロジェクトマネジメント実践論|現役エンジニアが語る!~チームでモノづくりをする時のコツとは?~
mixi_engineers
PRO
3
180
Featured
See All Featured
Fireside Chat
paigeccino
37
3.5k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.3k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Why Our Code Smells
bkeepers
PRO
336
57k
Statistics for Hackers
jakevdp
799
220k
GraphQLとの向き合い方2022年版
quramy
46
14k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Visualization
eitanlees
146
16k
Automating Front-end Workflow
addyosmani
1370
200k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
750
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に差し替えやすい
ご清聴ありがとうございました