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.8k
レイヤードアーキテクチャ(改) とDDD
レイヤードアーキテクチャ(改) とDDD
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
「ELT職人」から卒業!Fivetranでデータパイプラインの構築・運用から解放され、 本来の価値創造に集中できる ようになった事例
leveragestech
0
6
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
660
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
240
コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
leveragestech
0
130
AirflowでDataformを制御するポイント
leveragestech
0
120
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
1.3k
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
140
ディメンショナルモデリングを軽く語る
leveragestech
1
5.2k
アクターモデルによる効率的な分散システム設計
leveragestech
0
5k
Other Decks in Technology
See All in Technology
カンファレンスに託児サポートがあるということ / Having Childcare Support at Conferences
nobu09
1
450
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
230
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
240
多野優介
tanoyusuke
1
480
Vibe Coding Year in Review. From Karpathy to Real-World Agents by Niels Rolland, CEO Paatch
vcoisne
0
110
extension 現場で使えるXcodeショートカット一覧
ktombow
0
220
Azure Well-Architected Framework入門
tomokusaba
1
350
Geospatialの世界最前線を探る [2025年版]
dayjournal
0
170
許しとアジャイル
jnuank
1
140
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
180
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
230
from Sakichi Toyoda to Agile
kawaguti
PRO
1
100
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
620
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
KATA
mclloyd
32
15k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
BBQ
matthewcrist
89
9.8k
Six Lessons from altMBA
skipperchong
28
4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Building Applications with DynamoDB
mza
96
6.7k
How to Ace a Technical Interview
jacobian
280
24k
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に差し替えやすい
ご清聴ありがとうございました