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.9k
レイヤードアーキテクチャ(改) とDDD
レイヤードアーキテクチャ(改) とDDD
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
「ELT職人」から卒業!Fivetranでデータパイプラインの構築・運用から解放され、 本来の価値創造に集中できる ようになった事例
leveragestech
0
17
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
1.5k
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
250
コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
leveragestech
0
140
AirflowでDataformを制御するポイント
leveragestech
0
130
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
1.3k
リファクタリングいつやるの? 〜依存の整理〜
leveragestech
0
160
ディメンショナルモデリングを軽く語る
leveragestech
2
5.3k
アクターモデルによる効率的な分散システム設計
leveragestech
0
5.1k
Other Decks in Technology
See All in Technology
プレイドのユニークな技術とインターンのリアル
plaidtech
PRO
1
470
パフォーマンスチューニングのために普段からできること/Performance Tuning: Daily Practices
fujiwara3
2
140
AI時代、“平均値”ではいられない
uhyo
8
2.7k
NLPコロキウム20251022_超効率化への挑戦: LLM 1bit量子化のロードマップ
yumaichikawa
3
550
Oracle Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
0
380
組織全員で向き合うAI Readyなデータ利活用
gappy50
4
1.4k
マルチエージェントのチームビルディング_2025-10-25
shinoyamada
0
200
QA業務を変える(!?)AIを併用した不具合分析の実践
ma2ri
0
160
20251027_findyさん_音声エージェントLT
almondo_event
2
480
[re:Inent2025事前勉強会(有志で開催)] re:Inventで見つけた人生をちょっと変えるコツ
sh_fk2
1
810
オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability
kaminashi
1
1.1k
AI時代の発信活動 ~技術者として認知してもらうための発信法~ / 20251028 Masaki Okuda
shift_evolve
PRO
1
120
Featured
See All Featured
It's Worth the Effort
3n
187
28k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Writing Fast Ruby
sferik
630
62k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
Faster Mobile Websites
deanohume
310
31k
Bash Introduction
62gerente
615
210k
Build your cross-platform service in a week with App Engine
jlugia
233
18k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Reflections from 52 weeks, 52 projects
jeffersonlam
354
21k
Six Lessons from altMBA
skipperchong
29
4k
4 Signs Your Business is Dying
shpigford
185
22k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
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に差し替えやすい
ご清聴ありがとうございました