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

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

Transcript

1. レイヤードアーキテクチャ
   （とDDD）
   テックフェス2023春
   松浪 亮
   

   View Slide

2. Profile
   松浪 亮（まつなみ りょう）
   Matsunami Ryo
   出⾝：⼤阪府
   ⼊社：2022/01
   所属：レバテックID開発チーム
   最近のお気に⼊り
   

   View Slide

3. 今回お話しする内容は...
   レイヤードアーキテクチャ
   

   View Slide

4. 10か⽉くらい前にも話してたけど...
   ※ アーキテクチャスキルアッププロジェクト
   

   View Slide

5. 発表して半年経ってから
   いちゃもん
   コメントが...
   

   View Slide

6. 要約すると、

   「内容薄いからもっと詳しく書け」 

   発表して半年経ってから
   いちゃもん
   コメントが...
   

   View Slide

7. レイヤードアーキテクチャ（改）
   （とDDD）
   テックフェス2023春
   松浪 亮
   

   View Slide

8. 今回お話しする内容は...
   [1] レイヤードアーキテクチャについて、おさらい
   

   View Slide

9. 今回お話しする内容は...
   [1] レイヤードアーキテクチャについて、おさらい
   [2] コードを元にレイヤードアーキテクチャを解説
   

   View Slide

10. 今回お話しする内容は...
    [1] レイヤードアーキテクチャについて、おさらい
    [2] コードを元にレイヤードアーキテクチャを解説
    [3] DI(依存性の注⼊)でコードをドメイン中⼼に作り変える
    

    View Slide

11. ⽬次
    1. レイヤードアーキテクチャについて
    2. コードでレイヤードアーキテクチャを理解する
    3. DIでドメイン中⼼に作り変える
    4. まとめ
    

    View Slide

12. ⽬次
    1. レイヤードアーキテクチャについて
    2. コードでレイヤードアーキテクチャを理解する
    3. DIでドメイン中⼼に作り変える
    4. まとめ
    

    View Slide

13. レイヤードアーキテクチャ
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    

    View Slide

14. 4つのレイヤーに分けてモジュールを配置
    ■Infrastructure層
    データストアへの永続化や外部APIとの通信など技術
    的な機能を実装する
    ■Domain層
    ドメイン（ソフトウェアで解決したい対象領域のこ
    と）モデルのルール/制約を実装する
    ■Application層
    ドメイン層を組み合わせてユースケースを実装する
    ■Presentation層
    UIやユニットテストなど、アプリケーション（ユース
    ケース）層を呼び出すコードを実装する
    

    View Slide

15. ルールは１つだけ
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    依存OK
    依存NG
    

    View Slide

16. 依存関係について
    依存する側 依存される側
    依存⽅向
    

    View Slide

17. 依存関係について
    依存する側 依存される側
    依存⽅向
    変更
    依存関係について
    

    View Slide

18. 依存関係について
    依存する側 依存される側
    依存⽅向
    変更
    影響あり
    依存関係について
    

    View Slide

19. 依存関係について
    依存する側 依存される側
    依存⽅向
    変更
    影響あり
    変更
    依存関係について
    

    View Slide

20. 依存関係について
    依存する側 依存される側
    依存⽅向
    変更
    影響あり
    変更 影響なし
    依存関係について
    

    View Slide

21. 依存関係について
    依存する側は影響を与えないので改修・変更が容易になり、
    依存される側は変更の影響を受けないので依存する側よりも安定する。
    依存関係について
    依存する側 依存される側
    依存⽅向
    変更
    影響あり
    変更 影響なし
    

    View Slide

22. 依存関係について
    変更頻度が⾼い機能は依存する側（上位の層）に、
    変更の影響を受けたくない機能は依存される側（下位の層）に設計すべき。
    依存する側は影響を与えないので改修・変更が容易になり、
    依存される側は変更の影響を受けないので依存する側よりも安定する。
    依存関係について
    依存する側 依存される側
    依存⽅向
    変更
    影響あり
    変更 影響なし
    

    View Slide

23. レイヤードアーキテクチャの問題点
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    DomainがInfrastructureに依存してよいことになっている
    → 変更の影響を受けたくないはずのDomainが依存する側にある
    

    View Slide

24. レイヤードアーキテクチャの問題点２
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    理論上はPresentationもInfrastructureに依存してよい
    → Presentationからデータを更新できてしまう
    

    View Slide

25. ドメインルールがDomain層から漏れ出てしまう
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    理論上はPresentationもInfrastructureに依存してよい
    → Presentationからデータを更新できてしまう
    → 本来、Domainにあるべき実装を
      Presentationに実装できてしまう
    ドメイン
    ロジック
    

    View Slide

26. 全体を⾒ないと仕様を把握できなくなる
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    理論上はPresentationもInfrastructureに依存してよい
    → Presentationからデータを更新できてしまう
    → 本来、Domainにあるべき実装を
      Presentationに実装できてしまう
    → 修正箇所が分散する
    → 達成したいことは全体を⾒ないとわからない
    ドメイン
    ロジック
    ドメイン
    ロジック
    

    View Slide

27. 解決策
    エリック・エヴァンスのドメイン駆動設計（翔泳社）
    Infrastructureからの依存の向きを変える
    → 依存性を逆転させる
    

    View Slide

28. つまり...
    ドメイン駆動設計 モデリング/実装ガイド（松岡
    幸一郎さん：著）
    ドメインを中⼼に置く
    → ドメイン駆動設計
    

    View Slide

29. つまり...
    ドメイン駆動設計 モデリング/実装ガイド（松岡
    幸一郎さん：著）
    詳しくは...
    

    View Slide

30. ⽬次
    1. レイヤードアーキテクチャについて
    2. コードでレイヤードアーキテクチャを理解する
    3. DIでドメイン中⼼に作り変える
    4. まとめ
    

    View Slide

31. 例（コードサンプル）
    ● ユーザ情報を登録する超シンプルなWebアプリケーションを想定
    ○ ⼊⼒として、name（⽒名）とemail（メールアドレス）を受け取る
    ○ バリデーションチェックを実施する
    ○ バリデーションに問題なければRDBに登録する
    ● レイヤードアーキテクチャに則って実装してみる
    ○ Presentation層
    ■ → Application層
    ● → Domain層
    ○ → Infrastructure層
    

    View Slide

32. Presentation層
    

    View Slide

33. Presentation層
    Presentation層
    

    View Slide

34. Presentation層
    Presentation層
    

    View Slide

35. Application層
    

    View Slide

36. Application層
    

    View Slide

37. Application層
    

    View Slide

38. Domain層
    

    View Slide

39. Domain層
    新規ユーザを⽣成時のドメイン知識(ルール/制約)を実装
    →バリデーションチェックや初期設定など
    →常に正しいインスタンスしか存在させなくする
    

    View Slide

40. Infrastructure層
    

    View Slide

41. 結果...
    EndPoint（"/users/create"）
    UseCase
    Entity
    Repository
    

    View Slide

42. ⽬次
    1. レイヤードアーキテクチャについて
    2. コードでレイヤードアーキテクチャを理解する
    3. DIでドメイン中⼼に作り変える
    4. まとめ
    

    View Slide

43. ドメインを中⼼にするには...
    EndPoint（"/users/create"）
    

    UseCase

    Entity

    Repository
 ← Repositoryを...
    

    View Slide

44. EndPoint（"/users/create"）
    

    UseCase

    Repository

    Repository

    Entity

    ↑ DI（依存性の注⼊）する
    こうする...!!
    

    View Slide

45. こうする...??
    EndPoint（"/users/create"）
    

    UseCase

    Repository

    Repository

    Entity

    ↑ DI（依存性の注⼊）する
    

    View Slide

46. DI（依存性の注⼊）とは
    依存性の注⼊（いぞんせいのちゅうにゅう、英: Dependency injection）とは、あるオブジェ
    クトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。
    DIは制御の反転の⼀種で、オブジェクトの作成と利⽤について関⼼の分離を⾏い、疎結合な
    プログラムを実現することを⽬的としている。
    by Wikipedia
    

    View Slide

47. DI（依存性の注⼊）とは??
    依存性の注⼊（いぞんせいのちゅうにゅう、英: Dependency injection）とは、あるオブジェ
    クトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。
    DIは制御の反転の⼀種で、オブジェクトの作成と利⽤について関⼼の分離を⾏い、疎結合な
    プログラムを実現することを⽬的としている。
    by Wikipedia
    

    View Slide

48. Presentation層
    

    View Slide

49. Presentation層
    

    View Slide

50. Presentation層
    

    View Slide

51. Application層
    

    View Slide

52. ドメインを中⼼にするために...
    ・Repositoryのインタフェースを⽤意する
    ・Infrastructureの実態をコンストラクタで渡す
    

    View Slide

53. ドメインを中⼼にするために...
    ・Repositoryのインタフェースを⽤意する
    ・Infrastructureの実態をコンストラクタで渡す
     → DI（依存性の注⼊）
    

    View Slide

54. Application層
    

    View Slide

55. Application層
    Applicationからインタフェースを参照（依存）する形に
    なった
    → Repositoryのコードの詳細が⾒えなくなった
     → Infrastructureの実装に依存しなくなった！
    

    View Slide

56. Q.依存しなくなると何が嬉しいのか？
    

    View Slide

57. Q.依存しなくなると何が嬉しいのか？
    A.ユニットテストしやすくなる
    Q.依存しなくなると何が嬉しいのか？
    

    View Slide

58. ユニットテストでモックに差し替える
    ①インタフェースを実装したMockを⽤意する
     → 適当な値を返す
    ③RDBに接続しないでユニットテストができる
    ②コンストラクタでMockを渡す
    

    View Slide

59. 例外のパターンもテストしやすい
    ①インタフェースを実装したMockを⽤意する
     → 例外を返す
    ③例外のパターンもユニットテストができる
    ②コンストラクタでMockを渡す
    

    View Slide

60. ⽬次
    1. レイヤードアーキテクチャについて
    2. コードでレイヤードアーキテクチャを理解する
    3. DIでドメイン中⼼に作り変える
    4. まとめ
    

    View Slide

61. まとめ
    ● レイヤードアーキテクチャは下記の概念に沿って設計する
    ○ 4つのレイヤーで責務を分割する
    ○ 常に上位から下位の⽅向に依存させる
    ● ⽋点としてInfrastructure層に依存する設計となる
    ○ 依存関係を逆転させるためにDI（依存性の注⼊）を利⽤する
    ○ DIによってドメインを中⼼とした設計にすることができる
    ■ オニオンアーキテクチャが実現できる
    ● Infrastructure層に依存させないことでテストしやすくなる
    ○ Infrastructure層のコードの実態をMockに差し替えやすい
    

    View Slide

62. ご清聴ありがとうございました
    

    View Slide