Skip to content

πŸ—‚οΈ Folders and project organization ​

πŸ¦„ Backend ​

Layers ​

                                           ___ Models
                                          /
 Client -->   API       --> Services --> ORM
             urls+views                   \___ Manager
             Schemas        Rules
                                           ___ Models
                                          /
 Client -->   API       --> Services --> ORM
             urls+views                   \___ Manager
             Schemas        Rules
  • Client: Anything that does HTTP calls to the API
  • API: It has route definitions and input data validation, with little or no business rules. Redirects the data to the service layer.
  • Services: Pure Python modules with the implementation of business rules; it is the layer that must be tested the most.
  • ORM: Data mappping in the database

Folders structure ​

Overview

shell
twitterclone                       πŸ‘‰ Root folder
 β”œβ”€β”€ README.md
 β”œβ”€β”€ manage.py                     πŸ‘‰ Django CLI (Entry point)
 β”œβ”€β”€ requirements.txt              πŸ‘‰ Main dependencies
 β”œβ”€β”€ requirements-dev.txt          πŸ‘‰ Local dependencies (may change in Poetry mode)
 β”œβ”€β”€ docker-compose.yml            πŸ‘‰ Docker descriptor to run locally
 β”œβ”€β”€ Dockerfile                    πŸ‘‰ Recipe to run the project
 β”œβ”€β”€ tox.ini
 β”œβ”€β”€ uwsgi.ini
 └── twitterclone                  πŸ‘‰ Project base
    β”œβ”€β”€ base                       πŸ‘‰ App for rules outside the "core"
    β”‚   └── ...
    β”œβ”€β”€ accounts                   πŸ‘‰ App related to users and authentication
    β”‚   └── ...
    β”œβ”€β”€ core                       πŸ‘‰ Main app with the core business
    β”‚   └── ...
    └── twitterclone               πŸ‘‰ Centralizes project settings
        β”œβ”€β”€ api.py
        β”œβ”€β”€ settings.py            πŸ‘‰ Main Django settings
        β”œβ”€β”€ urls.py                πŸ‘‰ Main/initial configuration of Django routes
        └── wsgi.py
twitterclone                       πŸ‘‰ Root folder
 β”œβ”€β”€ README.md
 β”œβ”€β”€ manage.py                     πŸ‘‰ Django CLI (Entry point)
 β”œβ”€β”€ requirements.txt              πŸ‘‰ Main dependencies
 β”œβ”€β”€ requirements-dev.txt          πŸ‘‰ Local dependencies (may change in Poetry mode)
 β”œβ”€β”€ docker-compose.yml            πŸ‘‰ Docker descriptor to run locally
 β”œβ”€β”€ Dockerfile                    πŸ‘‰ Recipe to run the project
 β”œβ”€β”€ tox.ini
 β”œβ”€β”€ uwsgi.ini
 └── twitterclone                  πŸ‘‰ Project base
    β”œβ”€β”€ base                       πŸ‘‰ App for rules outside the "core"
    β”‚   └── ...
    β”œβ”€β”€ accounts                   πŸ‘‰ App related to users and authentication
    β”‚   └── ...
    β”œβ”€β”€ core                       πŸ‘‰ Main app with the core business
    β”‚   └── ...
    └── twitterclone               πŸ‘‰ Centralizes project settings
        β”œβ”€β”€ api.py
        β”œβ”€β”€ settings.py            πŸ‘‰ Main Django settings
        β”œβ”€β”€ urls.py                πŸ‘‰ Main/initial configuration of Django routes
        └── wsgi.py

Django has the concept of "apps", with the goal of separating your project contexts. Instead of having everything in the main app, we are able to create new apps (e.g. sales, purchases, inventory, reports, blog) in order to group similar functionalities. Each app follows the structure below:

   urls --> views --> service --> models
   1) Routes          2) Rules    3) Database
   urls --> views --> service --> models
   1) Routes          2) Rules    3) Database
shell
β”œβ”€β”€ core                       πŸ‘‰ Django app root to centralize a solution for a given context
β”‚   β”œβ”€β”€ apps.py                πŸ‘‰ As an app\'s __init__
β”‚   β”œβ”€β”€ urls.py                πŸ‘‰ 1) Routes definition (with django-ninja the urls are empty)
β”‚   β”œβ”€β”€ views.py               πŸ‘‰ 1) Routes implementation
β”‚   β”œβ”€β”€ schemas.py             πŸ‘‰ 1) Definition of the name/type attributes
β”‚   β”œβ”€β”€ service                πŸ‘‰ 2) Business rules implementation
β”‚   β”œβ”€β”€ models.py              πŸ‘‰ 3) Definition of the tables to store the data
β”‚   β”œβ”€β”€ migrations             πŸ‘‰ 3) History of how to create/alter tables in the database
β”‚   β”œβ”€β”€ admin.py               πŸ‘‰ Configuration of the data accessible through the back-office
β”‚   β”œβ”€β”€ tests                  πŸ‘‰ Centralizes app tests
β”‚   └── templates              πŸ‘‰ Not used in API apps, but can generate HTML page
β”œβ”€β”€ core                       πŸ‘‰ Django app root to centralize a solution for a given context
β”‚   β”œβ”€β”€ apps.py                πŸ‘‰ As an app\'s __init__
β”‚   β”œβ”€β”€ urls.py                πŸ‘‰ 1) Routes definition (with django-ninja the urls are empty)
β”‚   β”œβ”€β”€ views.py               πŸ‘‰ 1) Routes implementation
β”‚   β”œβ”€β”€ schemas.py             πŸ‘‰ 1) Definition of the name/type attributes
β”‚   β”œβ”€β”€ service                πŸ‘‰ 2) Business rules implementation
β”‚   β”œβ”€β”€ models.py              πŸ‘‰ 3) Definition of the tables to store the data
β”‚   β”œβ”€β”€ migrations             πŸ‘‰ 3) History of how to create/alter tables in the database
β”‚   β”œβ”€β”€ admin.py               πŸ‘‰ Configuration of the data accessible through the back-office
β”‚   β”œβ”€β”€ tests                  πŸ‘‰ Centralizes app tests
β”‚   └── templates              πŸ‘‰ Not used in API apps, but can generate HTML page

🎨 Frontend ​

🚧 TODO

You can help here!