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

Introduction to Clean Architecture

Introduction to Clean Architecture

75086cfa4a46d4aa47deb38b409bd9cd?s=128

Jun Tomioka

March 08, 2019
Tweet

Transcript

  1. Introduction to Clean Architecture @jooohn1234

  2. M3, Inc. @jooohn1234 じょんと呼んでください!

  3. “The goal of software architecture is to minimize the human

    resources required to build and maintain the required system.” (Martin, Robert C.. Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series) (p. 5). Pearson Education. Kindle Edition. )
  4. http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

  5. Clean Architectureの基本 • 近年のアーキテクチャをとりまとめたものである ◦ 層を分けることで関心を分離している ◦ テストが容易 ◦ 以下から独立している

    ▪ フレームワーク ▪ UI ▪ データベース ▪ その他外部とのやりとり
  6. Clean Architectureの基本 • 近年のアーキテクチャをとりまとめたものである ◦ 層を分けることで関心を分離している ◦ テストが容易 ◦ 以下から独立している

    ▪ フレームワーク ▪ UI ▪ データベース ▪ その他外部とのやりとり ビジネスロジックがこれらに強く依存し ていることでメンテしづらくなっている 状態・・・あるある
  7. 層と依存の方向 • Entities ◦ 事業におけるビジネスルール • Use Cases ◦ アプリケーションにおけるビジネスルール

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする
  8. 層と依存の方向 • Entities ◦ 事業におけるビジネスルール • Use Cases ◦ アプリケーションにおけるビジネスルール

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする Higher level policies Lower level details
  9. 層と依存の方向 • Entities ◦ 事業におけるビジネスルール • Use Cases ◦ アプリケーションにおけるビジネスルール

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする 変更に対する 理想の影響範囲
  10. 層と依存の方向 • Entities ◦ 事業におけるビジネスルール • Use Cases ◦ アプリケーションにおけるビジネスルール

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする あるべき 依存の方向
  11. 層と依存の方向 • Entities ◦ 事業におけるビジネスルール • Use Cases ◦ アプリケーションにおけるビジネスルール

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする 依存の方向 この層を技術的な詳細から守る あるべき 依存の方向
  12. 層と依存の方向 • Entities ◦ 事業におけるビジネスルール • Use Cases ◦ アプリケーションにおけるビジネスルール

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする 依存の方向 Use Caseの実現に永続層とのやり取りは必須で は・・・? あるべき 依存の方向
  13. DIP (Dependency Inversion Principle)

  14. DIP • 依存の方向を超えて機能を使いたい場合は、欲 しい機能のInterfaceを用意し、それに依存させる。 SOLIDのD。 https://en.wikipedia.org/wiki/Dependency_inversion_principle

  15. DIP • 依存の方向を超えて機能を使いたい場合は、欲 しい機能のInterfaceを用意し、それに依存させる。 SOLIDのD。 https://en.wikipedia.org/wiki/Dependency_inversion_principle レイヤーの境界

  16. Hexagonal Architecture (Ports and Adapter) • 特に永続化、UI、API等で外部とやりとりせざるを 得ないケースが多い。 • ドメイン層をDIPで具体的な利用技術から守るのが

    Hexagonal Architecture ◦ Ports -> Interfaces ◦ Adapters -> Implementations • Clean Architectureも大きく影響を受けている
  17. UseCase 実装例

  18. UseCaseが欲しい処理はPort (Interface)に依存

  19. Adapter は Port (Interface) を実装する

  20. UseCaseの作成時に実装を外部から注入

  21. ソースコードの依存の順番を 維持したまま 機能の依存を実現できた!

  22. 抽象化のうまみ

  23. Adapterの実装は差し替えられる

  24. None
  25. テスト用に実装の差し替え • DBに依存せずテストができる。 ◦ 結局DBの方もテストするが、テストする箇所はPortの要件 を満たしているかのみ。 ◦ Doctorsインターフェースに依存しているコンポーネントのテ ストはテスト用のもので十分。

  26. 他にもあったうまみ • プロトタイプで、いったんAdapterをインメモリのもの で実装 ◦ デプロイ時に状態が消滅するが、PoCには十分 ◦ 本稼働時はAdapterを差し替えるだけ。「負債化する雑なプ ロトタイプ」ではない。 •

    そして当時いったんAWSで構成していたが結局 GCPに移行した(RDS,S3 -> Cloud SQL,Cloud Storage) ◦ インメモリだったので影響なし • -> 利用技術の判断を遅らせることができた ◦ 仮に実装済みだったとしても、変更箇所は限定的
  27. CQRSとUseCases • CQRS ◦ Command (変更)と Query (問い合わせ)を明確に分けるのを アーキテクチャレベルでやる。 •

    UseCasesはCommandについての話だけでいいと思 う。 ◦ ビジネスルールはたいてい Commandに現れる ▪ Queryにおけるサーバー側の責務は認可くらい ◦ Queryは観測する側の都合なので一生懸命サーバー側で やるのはつらい。 ◦ 一般的なwebサーバのQueryはGraphQL最強では。
  28. Clean Architecture Controller GraphQL GraphQLと組み合わせたイメージ Query Queryの要件は様々なので抽象化は難 しい。 効率の良い方法で好きにとってくる。 Mutation

    UseCases
  29. そして • Clean Architectureでやってみると、「Use Casesとは? Entitiesとは?ぼくたちはこの重要なビジネスルー ルを正しく捉えられているのか?」という気持ちに なってくる。 ◦ ->

    ユースケース駆動、ドメイン駆動の世界 ▪ 巻き込み力が必要 • どこまで真面目にやる? ◦ ケースバイケースでしょう
  30. “The goal of software architecture is to minimize the human

    resources required to build and maintain the required system.” (Martin, Robert C.. Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series) (p. 5). Pearson Education. Kindle Edition. ) 再掲
  31. Clean Architectureまとめ • ビジネスルールを守るように層と依存を設計 • 依存の方向に違反するときはDIP • 結局重要なのはビジネスルールを正しく捉えるこ とではという気持ちになってくる •

    引き出しは持っておいて、現実(チームやビジネ ス)を見てうまいことやるのがいいと思う