Upgrade to Pro — share decks privately, control downloads, hide ads and more …

レイヤードアーキテクチャ(改) とDDD

レイヤードアーキテクチャ(改) とDDD

レイヤードアーキテクチャ(改) とDDD

More Decks by レバレジーズTechアカウント

Other Decks in Technology

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. ルールは1つだけ
    エリック・エヴァンスのドメイン駆動設計(翔泳社)
    依存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. レイヤードアーキテクチャの問題点2
    エリック・エヴァンスのドメイン駆動設計(翔泳社)
    理論上は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