The basic principle

Each App should only do one thing. Its function should use a simple statement can be described clearly, if the process is described by more than one "and" could mean this App a bit big, need to split.

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.'

How named Django App

Try to use a word such as Animals , Blog , Dreams , polls . Simple and clear semantic name of the project easier to maintain.
If appropriate, the name of the main data model can refer to the inner App, App name in plural form.
Consider naming form of a URL, such as blog's URL can be http://www.example.com/weblog/, you can consider App named weblog, rather than a blog or posts.
Full name with small print letters, numbers, etc. Do not use other characters, if needed, can be underlined _, but try to avoid using.

Hesitation when you use a small program App

App design and split functionality is an art, not technology. So the future may need to split reorganization.

App try to make a small enough compared to a large number of small App App easier to maintain.

Which modules have an App?

Common modules:

These modules can be seen in 99% of the Django App:

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

Less common module

# 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

Description of each module functions as follows:

Modules | Function Description
-------------- |
constants.py | App-level settings, if excessive App set value, should be separate in the file
decorators.py | App decorator
db / bag | customized data model items and other database-related components
fields.py | placed custom data model item, if not more database-related component, can only be placed in the file, without creating db package
factories.py | generating test data factory function
helpers.py | from views.py and models.py extracted some of the accessibility features function
utils.py | with helpers.py
managers.py | when models.py is large, it can be customized the model managers extracted
signals.py | custom signal
viewmixins.py | from views.py extracted in mixins

References: Two Scoops of the Django: Best Practices for the Django 1.8

Django basic design principles App