Introduction to Clean Architecture

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の実装は差し替えられる
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 • 結局重要なのはビジネスルールを正しく捉えるこ とではという気持ちになってくる • 引き出しは持っておいて、現実（チームやビジネ ス）を見てうまいことやるのがいいと思う