Project Structure¶

Top-level layout:

• app/: Django project and domain apps
• docs/: MkDocs configuration and documentation pages
• scripts/: utility scripts for testing, backups, and checks
• proxy/: NGINX image and templated config
• docker-compose.yml: local development stack
• docker-compose-deploy.yml: deployment-oriented stack

Within app/:

• app/: Django project package (settings.py, urls.py)
• core/: shared middleware, utilities, and base behavior
• *_mgmt/: domain modules (requirements, interfaces, scope, architecture, etc.)

Structure Map¶

flowchart TD
    A[Repository Root] --> B[app]
    A --> C[docs]
    A --> D[scripts]
    A --> E[proxy]
    A --> F[docker-compose.yml]
    A --> G[docker-compose-deploy.yml]
    B --> B1[app project package]
    B --> B2[core shared module]
    B --> B3[domain mgmt apps]

Runtime Topology¶

flowchart LR
    U[User Browser] --> N[NGINX Proxy deploy stack]
    N --> W[Django app service]
    W --> P[(PostgreSQL)]
    W --> R[(Redis)]
    C[Celery Worker] --> R
    C --> P

Design Intent¶

• Preserve clear separation between domain modules.
• Keep shared behavior and policy enforcement in core.
• Route ownership lives in each domain module.
• Favor explicit service boundaries over cross-app internals.

Architectural Principle¶

Domain apps should depend on shared components in core and avoid importing peer app internals directly.