ソフトウェア開発のフォルダ構成案

前回の記事 https://qiita.com/ikuo0/items/aee6aadd5c3be51d2a9f で処理概念をちゃんと分けましょうという話をしましたが、今回は具体的なフォルダ分けを提案します。

フォルダ構成ツリー

SaaS、ネイティブGUIで同じ構成で良いとは思います。　今までの慣例・文化と異なる部分もあるでしょけど。

• impl # rootフォルダ
  • ui # WEBフロントエンド、ネイティブアプリのView
    • src
      • screens # 画面単位の実装
      • usecases # service を組み合わせた処理はここ
      • services # 業務処理、だいたいの処理はこれだけで完結するはず
      • domain # アカウント、トークン、商品固有の構造といった業務・仕組み依存のルール処理、構造
      • infra # 外部サービス依存とか？多分滅多に使わない
      • tests # テストコード置き場
    • deploy # デプロイスクリプト
    • local_service # 検証用等、ローカルDockerサービス等
    • debug # 検証用スクリプト
  • application # SaaSだとbackend相当
    • src
      • usecases # service を組み合わせた処理はここ
      • services # 業務処理、だいたいの処理はこれだけで完結するはず
      • domain # アカウント、トークン、商品固有の構造といった業務・仕組み依存のルール処理、構造
      • infra # MySQL、DynamoDBみたいなリソース、外部サービス依存
      • tests # テストコード置き場
    • deploy # デプロイスクリプト
    • local_service # 検証用等、ローカルDockerサービス等
    • debug # 検証用スクリプト

各フォルダ末端のファイル配置例

例えば account という処理について

• application
  • src
    • domain
      • account
        • model.py # Account 構造体とか
        • domain.py # アカウントIDの発行、検証処理
        • repository.py # ※必要ならば

repository.py に関しては不要な場合も多いかと思います。

infra/dynamodb/repository～ あたりにテーブル読み書きを実装するため、accountの下には基本的に不要ですが、アカウント情報がDynamoDBとCognitoから入力、合体してアカウント情報が完成するといった場合には、account/repository.py で結合入力処理としたほうが良いと思います。

SaaS と ネイティブGUI で ui フォルダの使い方が変わるかも？

ネイティブGUIの場合は usecase や service は完全に不要かもしれません、言語も環境も同じですから、ui側の処理はapplication側の処理を使いまわせそうです。