基本原則

各Appは一つのことしかしないはずです.その機能は簡単な文ではっきり説明できるはずです.説明中に1つ以上の「および」を使った場合、このAppが少し大きくなったことを意味し、分割する必要があるかもしれません.
James Bennett:
The art of creating and maintaining a good Django app is that it should follow the truncated Unix philosophy according to Douglas McIlroy: 'Write programs that do one thing and do it well.'

Django Appの名前付け方法

できるだけanimals,blog,dreams,pollsなどの単語を使います.シンプルで意味のはっきりしたプロジェクト名は、メンテナンスが容易です.

が適切であれば、App内のプライマリ・データ・モデルの名前を参照してください.App名は複数の形式で使用されます.

の名前を付けるときにURLの形式を考慮します.例えば、blogのURLがhttp://www.example.com/weblog/であってもよいので、blogやpostsではなく、Appをweblogと命名することも考えられます.

は全小字のアルファベットで命名され、数字などの他の文字は使用しないでください.必要であれば、下線_を使用することができますが、できるだけ使用しないでください.

迷ったときは、アプリのプランを選びます

App機能の分割と設計は技術ではなく芸術です.だから後で分割再編が必要になるかもしれません.
1つのAppをできるだけ小さくし、複数の小さなAppは1つの大きなAppよりもメンテナンスしやすいようにします.

Appにはどのようなモジュールがありますか?

一般的なモジュール:

これらのモジュールは99%のDjango Appで見られます.

# Common modules
scoops/
    __init__.py
    admin.py
    forms.py
    management/
    migrations/
    models.py
    templatetags/
    tests/
    urls.py
    views.py

あまり見られないモジュール

# uncommon modules
scoops/
    behaviors.py
    constants.py
    context_processors.py
    decorators.py
    db/
    exceptions
    fields.py
    factories.py
    helpers.py
    managers.py
    middleware.py
    signals.py
    utils.py
    viewmixins.py

各モジュールの機能説明は以下の通りです.
モジュール
機能の説明
constants.py
Appレベルの設定値は、Appで設定値が多すぎる場合は、独立してファイルに保存する必要があります.
decorators.py
Appのアクセサリー
db/パッケージ
カスタムデータ・モデル・アイテムおよびその他のデータベース関連コンポーネント
fields.py
データベース関連コンポーネントが多くない場合は、dbパッケージを作成することなく、カスタムデータモデルアイテムを配置できます.
factories.py
テストデータを生成するファクトリ関数
helpers.py
viewsからpyとmodels.pyから抽出されたいくつかの補助機能関数
utils.py
同じだpy
managers.py
モデルとしてpyが大きい場合は、カスタマイズしたmodel managersを抽出できます
signals.py
カスタムシグナル
viewmixins.py
viewsからpyから抽出したmixins
参考文献:
Two Scoops of Django: Best Practices for Django 1.8