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

Introduction to Clean Architecture

Introduction to Clean Architecture

Jun Tomioka

March 08, 2019
Tweet

More Decks by Jun Tomioka

Other Decks in Technology

Transcript

  1. “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. )
  2. Clean Architectureの基本 • 近年のアーキテクチャをとりまとめたものである ◦ 層を分けることで関心を分離している ◦ テストが容易 ◦ 以下から独立している

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

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

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

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

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

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

    • Interface Adapters ◦ 外の世界のデータをUse Caseに必要な形に変換 • Frameworks & Drivers ◦ 外の世界と直接やり取りする 依存の方向 Use Caseの実現に永続層とのやり取りは必須で は・・・? あるべき 依存の方向
  9. 他にもあったうまみ • プロトタイプで、いったんAdapterをインメモリのもの で実装 ◦ デプロイ時に状態が消滅するが、PoCには十分 ◦ 本稼働時はAdapterを差し替えるだけ。「負債化する雑なプ ロトタイプ」ではない。 •

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

    UseCasesはCommandについての話だけでいいと思 う。 ◦ ビジネスルールはたいてい Commandに現れる ▪ Queryにおけるサーバー側の責務は認可くらい ◦ Queryは観測する側の都合なので一生懸命サーバー側で やるのはつらい。 ◦ 一般的なwebサーバのQueryはGraphQL最強では。
  11. そして • Clean Architectureでやってみると、「Use Casesとは? Entitiesとは?ぼくたちはこの重要なビジネスルー ルを正しく捉えられているのか?」という気持ちに なってくる。 ◦ ->

    ユースケース駆動、ドメイン駆動の世界 ▪ 巻き込み力が必要 • どこまで真面目にやる? ◦ ケースバイケースでしょう
  12. “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. ) 再掲