DjangoPlay — Application Architecture
DjangoPlay follows a layered application architecture. Incoming requests enter through the middleware and policy boundary, are routed to Django web views or DRF APIs, and then reach the application...
Application services coordinate business workflows and interact with domain models, asynchronous processing, and external integrations.
Architecture
flowchart TD
REQUEST["Incoming Request<br/>Browser / REST Client"]
MW["Middleware / Policies<br/>Authentication<br/>Security / Permissions<br/>Request Context"]
ROUTING["URL Routing<br/>/urlconf"]
WEB["Django Web Views<br/>Templates / UI"]
API["DRF APIs<br/>ViewSets / Views"]
SERVICES["Application Services<br/>Business Logic<br/>Workflows<br/>Validation<br/>Integration Orchestration"]
MODELS["Django Models<br/>Domain Data & Relationships"]
CELERY["Celery Tasks<br/>Asynchronous Work"]
INTEGRATIONS["Integrations / Services<br/>External Service Adapters"]
POSTGRES["PostgreSQL<br/>Application Data"]
REDIS["Redis<br/>Cache / Sessions / Celery"]
EXTERNAL["External APIs<br/>Third-Party Services"]
REQUEST --> MW
MW --> ROUTING
ROUTING --> WEB
ROUTING --> API
WEB --> SERVICES
API --> SERVICES
SERVICES --> MODELS
SERVICES --> CELERY
SERVICES --> INTEGRATIONS
MODELS --> POSTGRES
CELERY --> REDIS
INTEGRATIONS --> EXTERNAL
classDef request fill:#e6f1fb,stroke:#2474b5,stroke-width:2px,color:#174d7a
classDef security fill:#e5f6f1,stroke:#159a7a,stroke-width:2px,color:#075d4b
classDef presentation fill:#f5f3ed,stroke:#777777,stroke-width:1px,color:#444444
classDef service fill:#fff2d9,stroke:#d89b18,stroke-width:2px,color:#76520b
classDef backend fill:#eeeaff,stroke:#7655c7,stroke-width:2px,color:#4a3485
classDef external fill:#eeeeff,stroke:#5a55c9,stroke-width:2px,color:#403b91
class REQUEST request
class MW security
class ROUTING security
class WEB presentation
class API presentation
class SERVICES service
class MODELS backend
class CELERY backend
class INTEGRATIONS backend
class POSTGRES external
class REDIS external
class EXTERNAL external
`Request Flow
text
DJANGOPLAY WEB APPLICATION
│
▼
URL ROUTING
/urlconf
│
┌───────────┴───────────┐
▼ ▼
Django Web Views DRF APIs
Templates / UI ViewSets / Views
│ │
└───────────┬───────────┘
▼
MIDDLEWARE / POLICIES
• Authentication
• Security / Permissions
• Request Context
│
▼
APP SERVICES
• Business Logic
• Workflows
• Validation
• Integration Orchestration
│
┌──────────────┼──────────────┐
▼ ▼ ▼
DJANGO MODELS CELERY TASKS INTEGRATIONS
│ │ │
▼ ▼ ▼
PostgreSQL Redis External APIsArchitectural Responsibilities
| Layer | Responsibility |
|---|---|
| Middleware / Policies | Authentication, security, permissions, and request context |
| URL Routing | Maps incoming requests to the appropriate application endpoint |
| Django Web Views | Server-rendered web UI and Django view handling |
| DRF APIs | REST API endpoints implemented through DRF views and ViewSets |
| Application Services | Business logic, workflows, validation, and integration orchestration |
| Django Models | Domain data, relationships, and persistence-facing application state |
| Celery Tasks | Asynchronous and background processing |
| Integrations / Services | Communication with external services through integration boundaries |
| PostgreSQL | Persistent relational application data |
| Redis | Cache, sessions, and Celery-related infrastructure |
| External APIs | Third-party services consumed through integration boundaries |
Architectural Principle
The presentation layer should not contain core business workflows.
Django views and DRF APIs delegate application behavior to the service layer. Services coordinate domain models, asynchronous work, and external integrations.
This keeps the application modular and makes individual integration or infrastructure components replaceable without coupling them directly to the presentation layer.
Something wrong or missing on this page?Report a docs issue