2018-01-14追記
この記事の意見は、2018-01-14 現在の見解とは異なります。
最新の見解は こちら
を参照してください。
Django を実際にプロダクトで使用するとなると、まずプロジェクト構成をどうするか、という問題にぶち当たる。
ここでいう プロジェクト構成とは以下を指す。
- Djangoプロジェクトのディレクトリ構成
- Djangoアプリケーションの単位・ファイル構成
- settings管理方法
- 各Djangoアプリケーションごとの内部構成
現在の自分の意見をまとめてみると、こんな感じ
├── sampleapp
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── sampleapp_foo
│ ├── models.py
│ ├── urls.py
│ └── views.py
├── sampleapp_bar
│ ├── models.py
│ ├── urls.py
│ └── views.py
├── manage.py
├── requirements.txt
└── setup.py
ルートは作業ツリーのルートと同じ = READMEを置くところ。
sampleapp
がいわゆるプロジェクト名で、その配下にプロジェクトの設定をおいておく。
settings.pyは複数環境に対応できるよう、データベースの接続先URLなどの環境ごとに異なる値は環境変数から取得するようにする。
sampleapp/urls.py
にURLパターンを記述していくが、基本的に他のDjangoアプリケーションの
urls.py を読み込むだけにしておく。
sampleapp_foo がいわゆるDjangoアプリケーション。
モジュール名の重複を避けるため{プロジェクト名}_XXXX
みたいな感じにしている。基本的に、機能単位で作成し、機能的凝集を高める。（自然とbase
URLのサブディレクトリごとになることが多い）
Djangoアプリケーションの配置場所には、 sampleapp/foo
とか apps/foo とか sampleapp/apps/foo
とか、いろいろ流儀はあるようだが、
- Djangoアプリケーションはそれぞれで機能的に独立していることが望ましい
- Pythonではネストの深いパッケージはあまり見かけない
- Djangoアプリケーションは機能追加によりどんどん増えていく
という観点から sampleapp_foo にしている。
次点で、sampleapp/foo。
最初は作業ツリー直下に sampleapp_XXX
が増えていくのに抵抗があったが、今は慣れた。なにより目的のファイルを見つけやすいことが嬉しい。
models.pyは、大きくなったら models/XXX.py
みたいにmodelsディレクトリ作って、分割。models/__init__.py
内でmodelのクラスをimportして、Djangoから認識されるようにする。
だいたいこんな感じ。 これから更に、Djangoアプリケーション内でどのようにもジョールを定義していくか、という問題があるけれど、それはまた今度・・・