バックエンドのディレクトリ構成

前提

• Python/FastAPI
• OpenAPIやDBからのコード生成は行わない

参考

• 関数型ドメインモデリング
• 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発
• Feature Sliced Design
• Bulletproof React

Feature Sliced Designは他の機能の塊への依存を許容しないが、Bulletproof Reactは許容している

https://feature-sliced.design/docs/get-started/overview#slices

Slices cannot use other slices on the same layer, and that helps with high cohesion and low coupling.

https://github.com/alan2207/bulletproof-react/blob/5d1c7e57b1c0af2efcfca311aaa125c6fecef879/apps/react-vite/src/app/routes/app/discussions/discussion.tsx#L8

バックエンドのレイヤーはどのようなものがあるか挙げてみる
被りを気にせず

関数型ドメインモデリングは以下FDMと書く

• ドメインロジック
  • 1つのオブジェクトで表現されるロジック (ドメインオブジェクト)
  • 複数のオブジェクトで表現されるロジック (ドメインサービス)
• ドメイン特有ではないロジック
• DFDのワークフロー
  • ワークフロー特有のロジック
  • DFDのミニワークフロー
  • DFDのドメインワークフロー (DBアクセス以外の純粋な関数部分)
• DBアクセス
  • レコードの型
  • シンプルなDBアクセス関数
  • DBの不変条件を守ったアクセス関数
• API
  • データ型
  • ルーティング
  • ハンドラ
    • Web特有の部分
    • 処理の流れ (ユースケース？)
• 共通処理
  • 環境変数
  • 認証

ここから適宜レイヤーをまとめ、依存関係を整理し、ディレクトリ構造に落とし込むことを考える

手を動かしてわかるクリーンアーキテクチャではデータ詰め替え戦略の第一の候補として以下を挙げている

• Write
  • API、ドメインではモデルを変換する
  • ドメイン、DBではモデルを共有する
• Read
  • API、ドメイン、DBでモデルを共有する

ユースケースがAPIと一対一対応しないっぽい書き方になっているので自分の想像するユースケースとは違うかもしれない
後で読み直す

『手を動かしてわかるクリーンアーキテクチャ』ではユースケースがインターフェイスで、サービスがその実装なのか