generated from bisco/codex-bootstrap
36 lines
1.1 KiB
Markdown
36 lines
1.1 KiB
Markdown
# ADR-0001: Use Django Monolith
|
|
|
|
Date: 2026-04-28
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
AzioneLab needs a public theatre company website, a simple booking system, administration tools, email confirmation, QR code generation, and entrance check-in.
|
|
|
|
The project is small enough that separate backend services would add operational cost without clear benefit. The selected backend stack is Python, Django 5.2 LTS, Django REST Framework, PostgreSQL, and gunicorn.
|
|
|
|
## Decision
|
|
|
|
Use a single Django monolith for the backend.
|
|
|
|
The Django application will own:
|
|
|
|
- public REST APIs;
|
|
- booking and confirmation logic;
|
|
- QR code generation;
|
|
- check-in validation;
|
|
- Django admin for internal management;
|
|
- database transactions for capacity enforcement.
|
|
|
|
The Angular frontend remains a separate client application served through nginx.
|
|
|
|
## Consequences
|
|
|
|
- The system stays simple to develop, deploy, and operate.
|
|
- Django admin can cover the initial administration needs without building custom admin screens immediately.
|
|
- Booking and capacity rules can be enforced close to the data model.
|
|
- The monolith may need to be split later if traffic, team size, or operational needs grow.
|