Djangoのディレクトリ構造のベストプラクティスを考えた

Railsを長くやっているというのもあるが、Railsのディレクトリ構造はわかりやすいなと常々感じる。Djangoで何か作る時もいつも構造には悩まされるので、いっそのことRails likeな構造にしてしまったらいいのでは？というところに着地した。
また、Djangoは１クラス１ファイルな方針はとっていないようだが、個人的には可読性と統一性のために１クラス１ファイルでやって行きたいと考える（現状）
(python自体はそれを推奨していないが）

また、言語によって常識は変わってくると思っているので、今後このような思考とは別のものになっていると思うが、現状考えていることをアウトプットしていく。

- top Directory(project-name)
  - config (project - directory)
    - __init__.py
    - settings.py
    - urls.py
    - wsgi.py
    
  - app (application - directory)
    - __init__.py
    - admin.py
    - apps.py
    - migrations/
      - __init__.py      
    - views
      - __init__.py
      - resources_view.py (resourcesの箇所は任意 ex: - users, posts etc)
    - models
      - __init__.py
      - resource.py (resourceの箇所は任意 ex: - user, post etc)
    - tests
      - __init__.py
      - 

config

projectを作成する際に、project-nameを指定するのではなく、configを指定する。

project - directoryは主にアプリケーション全体に関連する設定ファイルをまとめておくディレクトリという認識のため、configという名前にする。

Railsでも同様に、configがあり、アプリケーション全体の設定ファイルがまとまっている

実際に現場で使う際は、さらにsettings.pyなどは、各環境ごとにdirectory分けしておくなどの工夫が必要になってくる

app

ウェブサービスに必要な機能を実装していくためのディレクトリとして、Rails同様にappディレクトリは以下に各機能を実装するように設計

また、modelsやviewsは１クラス１ファイルに対応させるようにする。

最後に、

実際に現場でDjangoを使っているわけではないので、これが本当のベストプラクティスかどうかは不明。実際に現場ではどのようなディレクトリ構造になっているのか拝見したい。　

この設計思想はかなりRailsに引っ張られているため、もっとDjangoについて勉強したり、Djangoにて開発していくと見えるものが変わってきそう。

また、他のフレームワーク等ではどのような構造になっているかも気になるところ。

オレオレベストプラクティスはRailsしか触ってきていない人間がDjangoを触るとわかりづらい構造だなと思い、Rails likeになった感が否めないものになってしまった