Project Structure

Introduction

The difference in structure of each project makes it developers difficult to understand the code. This standard comes to solve this problem and to reduce the time used when developers study the project.

Structure

IMPORTANT: Every file/directory name should be snake_case

Note: __init__.py is omitted

    •
    ├── [project_name]/
    │   ├── apps/
    │   │   ├── common/ 19
    │   │   │   └── fixture_templates.py 
    │   │   │   └── ..
    │   │   ├── [app1_name]/ 1
    │   │   │   ├── fixtures/ 21
    │   │   │   ├── management/
    │   │   │   │   └── commands/
    │   │   │   ├── migrations/
    │   │   │   ├── templates/
    │   │   │   │   ├── css/ 11
    │   │   │   │   ├── fonts/ 11
    │   │   │   │   ├── images/ 11
    │   │   │   │   └── [template_name].html
    │   │   │   ├── tests/
    │   │   │   │   ├── test_[topic_name].py
    │   │   │   │   └── ..
    │   │   │   ├── admin.py
    │   │   │   ├── apps.py
    │   │   │   ├── choices.py 12
    │   │   │   ├── exceptions.py
    │   │   │   ├── factories.py 13
    │   │   │   ├── filters.py 14
    │   │   │   ├── functions.py 15
    │   │   │   ├── managers.py
    │   │   │   ├── models.py
    │   │   │   ├── paginations.py
    │   │   │   ├── permissions.py
    │   │   │   ├── serializers.py
    │   │   │   ├── services.py 20
    │   │   │   ├── signals.py
    │   │   │   ├── tasks.py 16
    │   │   │   ├── utils.py 17
    │   │   │   └── views.py
    │   │   │   └── ..
    │   │   ├── [app2_name]/
    │   │   │   └── ..
    │   │   └── ..
    │   ├── api_urls.py 2
    │   ├── asgi.py 7
    │   ├── celery.py 8
    │   ├── settings.py
    │   ├── urls.py 3
    │   └── wsgi.py 9
    ├── locales/
    │   ├── [lang]/
    │   │   └── LC_MESSAGES/
    │   │       └── django.po
    │   └── ..
    ├── static/ 10
    │   ├── css/
    │   ├── fonts/
    │   ├── images/
    │   └── ..
    ├── .flake8 4
    ├── .coveragerc 5
    ├── .gitignore 6
    ├── Dockerfile
    ├── manage.py
    ├── requirements.in 18
    └── requirements.txt 18

Explanation

^[1] Application Name

Every applciation name should be noun, is in the plural form, and using underscore (_) to improve readability ^[*]. common is an exception.

memos            # Yes
monthly_reports  # Yes

person           # No, because it is in singular form
externalservices # No, because it didn't use underscore

^[*] There is no best practice choosing between singular or plural form but it should match PEP8's Package and Module Names.

^[2] api_urls.py

It should contains only Django REST Framework's router and urlpatterns.

^[3] urls.py

It should contains only top-level urlpatterns. That is urlpatterns from any other packages including api_urls.py

^[4] .flake8

See: Flake8

^[5] .coveragerc

See: Coverage.py

^[6] .gitignore

It should contains only gitignore for Django/Python application only.

See: What is .gitignore?

^[7] asgi.py

It is not required if your application is not using ASGI.

^[8] celery.py

It is not required if your application is not using Celery.

^[9] wsgi.py

It is not required if your application is not using WSGI.

^[10] Static Across Applications

Static files here should be used across many applications in the project.

^[11] Static for Application's Template

Static files here should be used only in the certain application's template.

^[12] choices.py

Contains Django's Enumeration types class definitions

^[13] factories.py

Contains Factory Boy factories

^[14] filters.py

Contains django-filter classes

^[15] functions.py

Contains functions which are related with the business logic. Most of functions should be in this file. For example:

• Function to calculate SLA from work hour
• Function to removing expired products
• etc

^[16] tasks.py

Contains Celery tasks

^[17] utils.py

Contains utility functions which are not related with the business logic. For example:

• Date formatting
• Manipulating string
• etc

^[18] Requirements

Using pip-tools you can compile requirements.in into requirements.txt automatically.

^[19] common Application

The common application is the application that you can put any code which is reused in many applications. You can put filters, permission classes, managers, and etc here. This is because of the DRY principle.

Note: Inside common application, it should follow the standard of application as well.

^[20] Third-Party Services

If your application connects to third-party services, this is where you want to put the service-related logics.

_{[21] Fixtures}

Put your JSON fixtures here.

_{[22] Fixture Template}

Contain reusable set of fixtures, read more here.