Open1

Python + Clean Architectureを考える

H.P.YancyH.P.Yancy

背景

FastAPIのプロジェクトでClean Architectureを採用する場合どうしたらいいのか気になったので調査。
調査しても理解したこととモヤモヤしたことがあったので書き残しておく。
後で記事にするかも。

Clean Architectureの原文

Uncle Bobの記事を読んでみた
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

理解したことは下記。

  • 依存関係(Dependencies)の向きは一方向のみ(外側 → 内側)
  • レイヤは4つ存在(が必ずしも固定ではないらしい...)
    • Domain: ビジネスルールの集まり。一番コアなレイヤ
    • Usecase: アプリケーション固有のビジネスルールでDomainのみに依存するレイヤ
    • Infrastructure / Persistence Layer: データベースアクセス、API呼び出しなど、外部との接続が必要になるレイヤ
  • Interface / Adapter / Presentation Layer: UI, Web/API Controllers, UI Logic... の実際にUserが目にするデータを担うレイヤ
  • 構造の振る舞いに対して頑健かつUnit Test実行しやすくする

Python + FastAPIの場合

これをPython + FastAPIの実装に落とし込む際のイメージがなんとなく湧かなかったので調査開始。
英語で「Clean Architecture with Python」と調べて最初に出てきた英語の記事を読んでみた。
https://medium.com/@shaliamekh/clean-architecture-with-python-d62712fd8d4f

Uncle Bob の Clean Architecture で一般的なレイヤーと、この記事で使われているdirectoryを対応させると次のようになりそう。

  • Domain ---> domain/entities, domain/value_objects
  • Use Case ---> use_cases/submit_bid_use_case.py etc...
  • Interface / Adapters ---> ports/repositories/auction_repository.py, adapters/repositories/auction_repository.py
  • Infrastructure / Presentation ---> drivers/rest/...

質問リスト

自身への備忘録的に質問/モヤモヤを列挙

  • 外部APIの呼び出しが多いprojectだとusecaseの処理が肥大化してしまうのでは?
  • Interfaceはusecaseのinputになることが多いので、infrastructure側の変更がusecaseに振る舞いの変更を与える可能性があるけど、この時に「依存関係(Dependencies)の向きは一方向のみ(外側 → 内側)」をどう担保したらいいのか?
  • DTO的な処理はどこにかくの? stack over flowにも同じようなコメントがあった
    https://stackoverflow.com/questions/54748149/where-i-should-put-my-dtos-in-clean-architecture?utm_source=chatgpt.com

本読め!ていたらく!と言われそうなので、一応本は買った。
Clean Architecture 達人に学ぶソフトウェアの構造と設計