ねことくまとへび

Djangoによる開発でもやもやしている部分があるので、不明点を明確にするために文章にまとめてみます。しばらく後に見返したときに笑い話になっているといいな。

私はこれまでにDjangoを使ってTustle!というサービスと、流山百歌というサービスを作りました。

しかし、どちらも完成までは漕ぎ着けましたが、これをもってDjangoを理解したとは言いがたい状況です。特にProject内のApplicationの扱いについて。そして、Applicationを細かく分けたときのModelsの分割について。

Tustle!ではユーザー認証を司る「twingo」、それ以外の業務機能を担当する「tustle」の2つのApplicationを作成しました。そして、twingoのModelsにはユーザー情報のテーブル（Django1.4なのでカスタムユーザーモデルではなくProfile）、tustleにはそれ以外のテーブルを配置しました。このときは（それが良い作りであるかどうかは別にして）作っていく中で構造に迷いが生じたことはありません。

しかし、その後いろいろと調べていくうちに、どうやらDjangoではもう少し細かい粒度でApplicationを分割するべき、ということを学びました。

それを踏まえ、流山百歌では「100か所一覧」「俳句一覧」……など、かなり細かい単位でApplicationを作成しました。しかし、このときにModelsをどうすべきかに相当迷っています。

当初はそのテーブルにレコードを作成する機能を持つApplicationのModelsにそのテーブルを置こうかと考えました。しかし、例えば俳句関連のテーブルを俳句投稿のApplicationに置くことはいいとしても、日次バッチ処理で定期的にWeb APIから取得した情報で更新するようなテーブルの扱いはどうすればいいのでしょうか。バッチ処理をまとめたApplicationの下に置くのもちょっと違和感があります。

結局、このときは「core」というApplicationを作り、システムの全テーブルの定義をそこのModelsに書いています。そうするとその他のApplicationのModelsが空になってしまって寂しいので、それらについては「MVCのM」ととらえ、テーブルの定義ではなくビジネスロジックを書く場所にしています。「core」の特別扱いを許すのであれば、一応一貫したルールにはなっていますが、やはりオレオレルールであることには変わりがありません。

Projectを複数Applicationに分けて、その中でまたがって利用されるModelを定義する場合、どのようにするのが一般的なんですかね？　もしかして、相互にModelが依存するような単位でApplicationを分割してしまうこと自体が間違いだったりするのでしょうか……。