Tweet
Tweet

Slide 1

Slide 1 text

Introduction to Clean Architecture @jooohn1234

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

“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. )

Slide 4

Slide 4 text

http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Clean Architectureの基本 ● 近年のアーキテクチャをとりまとめたものである ○ 層を分けることで関心を分離している ○ テストが容易 ○ 以下から独立している ■ フレームワーク ■ UI ■ データベース ■ その他外部とのやりとり ビジネスロジックがこれらに強く依存し ていることでメンテしづらくなっている 状態・・・あるある

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

層と依存の方向 ● Entities ○ 事業におけるビジネスルール ● Use Cases ○ アプリケーションにおけるビジネスルール ● Interface Adapters ○ 外の世界のデータをUse Caseに必要な形に変換 ● Frameworks & Drivers ○ 外の世界と直接やり取りする 依存の方向 Use Caseの実現に永続層とのやり取りは必須で は・・・？ あるべき 依存の方向

Slide 13

Slide 13 text

DIP (Dependency Inversion Principle)

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Hexagonal Architecture (Ports and Adapter) ● 特に永続化、UI、API等で外部とやりとりせざるを 得ないケースが多い。 ● ドメイン層をDIPで具体的な利用技術から守るのが Hexagonal Architecture ○ Ports -> Interfaces ○ Adapters -> Implementations ● Clean Architectureも大きく影響を受けている

Slide 17

Slide 17 text

UseCase 実装例

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Adapter は Port (Interface) を実装する

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

抽象化のうまみ

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

他にもあったうまみ ● プロトタイプで、いったんAdapterをインメモリのもの で実装 ○ デプロイ時に状態が消滅するが、PoCには十分 ○ 本稼働時はAdapterを差し替えるだけ。「負債化する雑なプ ロトタイプ」ではない。 ● そして当時いったんAWSで構成していたが結局 GCPに移行した(RDS,S3 -> Cloud SQL,Cloud Storage) ○ インメモリだったので影響なし ● -> 利用技術の判断を遅らせることができた ○ 仮に実装済みだったとしても、変更箇所は限定的

Slide 27

Slide 27 text

CQRSとUseCases ● CQRS ○ Command (変更)と Query (問い合わせ)を明確に分けるのを アーキテクチャレベルでやる。 ● UseCasesはCommandについての話だけでいいと思 う。 ○ ビジネスルールはたいてい Commandに現れる ■ Queryにおけるサーバー側の責務は認可くらい ○ Queryは観測する側の都合なので一生懸命サーバー側で やるのはつらい。 ○ 一般的なwebサーバのQueryはGraphQL最強では。

Slide 28

Slide 28 text

Clean Architecture Controller GraphQL GraphQLと組み合わせたイメージ Query Queryの要件は様々なので抽象化は難 しい。 効率の良い方法で好きにとってくる。 Mutation UseCases

Slide 29

Slide 29 text

そして ● Clean Architectureでやってみると、「Use Casesとは？ Entitiesとは？ぼくたちはこの重要なビジネスルー ルを正しく捉えられているのか？」という気持ちに なってくる。 ○ -> ユースケース駆動、ドメイン駆動の世界 ■ 巻き込み力が必要 ● どこまで真面目にやる？ ○ ケースバイケースでしょう

Slide 30

Slide 30 text

“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. ) 再掲

Slide 31

Slide 31 text

Clean Architectureまとめ ● ビジネスルールを守るように層と依存を設計 ● 依存の方向に違反するときはDIP ● 結局重要なのはビジネスルールを正しく捉えるこ とではという気持ちになってくる ● 引き出しは持っておいて、現実（チームやビジネ ス）を見てうまいことやるのがいいと思う