レイヤードアーキテクチャ（改） とDDD

レイヤードアーキテクチャ（改） とDDD

Transcript

1. レイヤードアーキテクチャ （とDDD） テックフェス2023春 松浪 亮
2. Profile 松浪 亮（まつなみ りょう） Matsunami Ryo 出⾝：⼤阪府 ⼊社：2022/01 所属：レバテックID開発チーム 最近のお気に⼊り
3. 今回お話しする内容は... レイヤードアーキテクチャ
4. 10か⽉くらい前にも話してたけど... ※ アーキテクチャスキルアッププロジェクト
5. 発表して半年経ってから いちゃもん コメントが...
6. 要約すると、
 「内容薄いからもっと詳しく書け」 
 発表して半年経ってから いちゃもん コメントが...
7. レイヤードアーキテクチャ（改） （とDDD） テックフェス2023春 松浪 亮
8. 今回お話しする内容は... [1] レイヤードアーキテクチャについて、おさらい
9. 今回お話しする内容は... [1] レイヤードアーキテクチャについて、おさらい [2] コードを元にレイヤードアーキテクチャを解説
10. 今回お話しする内容は... [1] レイヤードアーキテクチャについて、おさらい [2] コードを元にレイヤードアーキテクチャを解説 [3] DI(依存性の注⼊)でコードをドメイン中⼼に作り変える
11. ⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
12. ⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
13. レイヤードアーキテクチャ エリック・エヴァンスのドメイン駆動設計（翔泳社）
14. 4つのレイヤーに分けてモジュールを配置 ▪Infrastructure層 データストアへの永続化や外部APIとの通信など技術 的な機能を実装する ▪Domain層 ドメイン（ソフトウェアで解決したい対象領域のこ と）モデルのルール/制約を実装する ▪Application層 ドメイン層を組み合わせてユースケースを実装する ▪Presentation層 UIやユニットテストなど、アプリケーション（ユース ケース）層を呼び出すコードを実装する
15. ルールは１つだけ エリック・エヴァンスのドメイン駆動設計（翔泳社） 依存OK 依存NG
16. 依存関係について 依存する側 依存される側 依存⽅向
17. 依存関係について 依存する側 依存される側 依存⽅向 変更 依存関係について
18. 依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 依存関係について
19. 依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更 依存関係について
20. 依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更 影響なし 依存関係について
21. 依存関係について 依存する側は影響を与えないので改修・変更が容易になり、 依存される側は変更の影響を受けないので依存する側よりも安定する。 依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更 影響なし
22. 依存関係について 変更頻度が⾼い機能は依存する側（上位の層）に、 変更の影響を受けたくない機能は依存される側（下位の層）に設計すべき。 依存する側は影響を与えないので改修・変更が容易になり、 依存される側は変更の影響を受けないので依存する側よりも安定する。 依存関係について 依存する側 依存される側 依存⽅向 変更 影響あり 変更 影響なし
23. レイヤードアーキテクチャの問題点 エリック・エヴァンスのドメイン駆動設計（翔泳社） DomainがInfrastructureに依存してよいことになっている → 変更の影響を受けたくないはずのDomainが依存する側にある
24. レイヤードアーキテクチャの問題点２ エリック・エヴァンスのドメイン駆動設計（翔泳社） 理論上はPresentationもInfrastructureに依存してよい → Presentationからデータを更新できてしまう
25. ドメインルールがDomain層から漏れ出てしまう エリック・エヴァンスのドメイン駆動設計（翔泳社） 理論上はPresentationもInfrastructureに依存してよい → Presentationからデータを更新できてしまう → 本来、Domainにあるべき実装を   Presentationに実装できてしまう ドメイン ロジック
26. 全体を⾒ないと仕様を把握できなくなる エリック・エヴァンスのドメイン駆動設計（翔泳社） 理論上はPresentationもInfrastructureに依存してよい → Presentationからデータを更新できてしまう → 本来、Domainにあるべき実装を   Presentationに実装できてしまう → 修正箇所が分散する → 達成したいことは全体を⾒ないとわからない ドメイン ロジック ドメイン ロジック
27. 解決策 エリック・エヴァンスのドメイン駆動設計（翔泳社） Infrastructureからの依存の向きを変える → 依存性を逆転させる
28. つまり... ドメイン駆動設計 モデリング/実装ガイド（松岡 幸一郎さん：著） ドメインを中⼼に置く → ドメイン駆動設計
29. つまり... ドメイン駆動設計 モデリング/実装ガイド（松岡 幸一郎さん：著） 詳しくは...
30. ⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
31. 例（コードサンプル） • ユーザ情報を登録する超シンプルなWebアプリケーションを想定 ◦ ⼊⼒として、name（⽒名）とemail（メールアドレス）を受け取る ◦ バリデーションチェックを実施する ◦ バリデーションに問題なければRDBに登録する • レイヤードアーキテクチャに則って実装してみる ◦ Presentation層 ▪ → Application層 • → Domain層 ◦ → Infrastructure層
32. Presentation層
33. Presentation層 Presentation層
34. Presentation層 Presentation層
35. Application層
36. Application層
37. Application層
38. Domain層
39. Domain層 新規ユーザを⽣成時のドメイン知識(ルール/制約)を実装 →バリデーションチェックや初期設定など →常に正しいインスタンスしか存在させなくする
40. Infrastructure層
41. 結果... EndPoint（"/users/create"） UseCase Entity Repository
42. ⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
43. ドメインを中⼼にするには... EndPoint（"/users/create"） 
 UseCase
 Entity
 Repository
 ← Repositoryを...
44. EndPoint（"/users/create"） 
 UseCase
 Repository
 Repository
 Entity
 ↑ DI（依存性の注⼊）する こうする...!!
45. こうする...?? EndPoint（"/users/create"） 
 UseCase
 Repository
 Repository
 Entity
 ↑ DI（依存性の注⼊）する
46. DI（依存性の注⼊）とは 依存性の注⼊（いぞんせいのちゅうにゅう、英: Dependency injection）とは、あるオブジェ クトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。 DIは制御の反転の⼀種で、オブジェクトの作成と利⽤について関⼼の分離を⾏い、疎結合な プログラムを実現することを⽬的としている。 by Wikipedia
47. DI（依存性の注⼊）とは?? 依存性の注⼊（いぞんせいのちゅうにゅう、英: Dependency injection）とは、あるオブジェ クトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。 DIは制御の反転の⼀種で、オブジェクトの作成と利⽤について関⼼の分離を⾏い、疎結合な プログラムを実現することを⽬的としている。 by Wikipedia
48. Presentation層
49. Presentation層
50. Presentation層
51. Application層
52. ドメインを中⼼にするために... ・Repositoryのインタフェースを⽤意する ・Infrastructureの実態をコンストラクタで渡す
53. ドメインを中⼼にするために... ・Repositoryのインタフェースを⽤意する ・Infrastructureの実態をコンストラクタで渡す  → DI（依存性の注⼊）
54. Application層
55. Application層 Applicationからインタフェースを参照（依存）する形に なった → Repositoryのコードの詳細が⾒えなくなった  → Infrastructureの実装に依存しなくなった！
56. Q.依存しなくなると何が嬉しいのか？
57. Q.依存しなくなると何が嬉しいのか？ A.ユニットテストしやすくなる Q.依存しなくなると何が嬉しいのか？
58. ユニットテストでモックに差し替える ①インタフェースを実装したMockを⽤意する  → 適当な値を返す ③RDBに接続しないでユニットテストができる ②コンストラクタでMockを渡す
59. 例外のパターンもテストしやすい ①インタフェースを実装したMockを⽤意する  → 例外を返す ③例外のパターンもユニットテストができる ②コンストラクタでMockを渡す
60. ⽬次 1. レイヤードアーキテクチャについて 2. コードでレイヤードアーキテクチャを理解する 3. DIでドメイン中⼼に作り変える 4. まとめ
61. まとめ • レイヤードアーキテクチャは下記の概念に沿って設計する ◦ 4つのレイヤーで責務を分割する ◦ 常に上位から下位の⽅向に依存させる • ⽋点としてInfrastructure層に依存する設計となる ◦ 依存関係を逆転させるためにDI（依存性の注⼊）を利⽤する ◦ DIによってドメインを中⼼とした設計にすることができる ▪ オニオンアーキテクチャが実現できる • Infrastructure層に依存させないことでテストしやすくなる ◦ Infrastructure層のコードの実態をMockに差し替えやすい
62. ご清聴ありがとうございました