ποΈ 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!