Django Service
Implement the business brain of an approved use case without coupling it to HTTP or Django persistence.
Required Context
Read AGENTS.md, relevant docs/product/ business rules, docs/architecture/domain-model.md, docs/architecture/api-contract.md, docs/architecture/backend-implementation-contract.md, docs/architecture/backend-contract-manifest.json, .codex/references/service-layer.md, .codex/references/repository-policy.md, and .codex/references/module-documentation.md.
Require an approved implementation contract. Stop if a business invariant, permission decision, transaction expectation, or failure state is missing or contradictory.
Workflow
- Identify Service input, result, dependencies, manifest invariant IDs, and expected domain errors.
- Inject Repository, Unit of Work, clock, identifier, or integration contracts explicitly.
- Enforce business invariants and coordinate the use case in
services/<use_case>.py.
- Return persistence-neutral results and raise approved domain/application errors.
- Add a meaningful opening docstring naming responsibility, boundaries, and relevant business rules.
- Add every exact manifest Service test with fakes and no database or HTTP client.
Boundaries
- Do not accept HTTP request objects or return framework responses.
- Do not import ORM Models,
django.db, managers, QuerySets, Controllers, or application Mappers.
- Do not query or persist directly; use Repository or Unit of Work contracts.
- Do not invent permissions, billing, sensitive-data, tenant, or lifecycle behavior.
Finish only when business rules are traceable, dependencies are explicit, Service tests are persistence-free, and no HTTP or ORM coupling remains.
1---2name: django-service3description: Implement approved backend business rules and application workflows in persistence-agnostic Django Service modules. Use when coordinating Repository contracts, enforcing numbered business rules, managing domain decisions, or producing Service results. Do not use for HTTP endpoints, DTO parsing, ORM Models, QuerySets, direct database access, or representation mapping.4---56# Django Service78Implement the business brain of an approved use case without coupling it to HTTP or Django persistence.910## Required Context1112Read `AGENTS.md`, relevant `docs/product/` business rules, `docs/architecture/domain-model.md`, `docs/architecture/api-contract.md`, `docs/architecture/backend-implementation-contract.md`, `docs/architecture/backend-contract-manifest.json`, `.codex/references/service-layer.md`, `.codex/references/repository-policy.md`, and `.codex/references/module-documentation.md`.1314Require an approved implementation contract. Stop if a business invariant, permission decision, transaction expectation, or failure state is missing or contradictory.1516## Workflow17181. Identify Service input, result, dependencies, manifest invariant IDs, and expected domain errors.192. Inject Repository, Unit of Work, clock, identifier, or integration contracts explicitly.203. Enforce business invariants and coordinate the use case in `services/<use_case>.py`.214. Return persistence-neutral results and raise approved domain/application errors.225. Add a meaningful opening docstring naming responsibility, boundaries, and relevant business rules.236. Add every exact manifest Service test with fakes and no database or HTTP client.2425## Boundaries2627- Do not accept HTTP request objects or return framework responses.28- Do not import ORM Models, `django.db`, managers, QuerySets, Controllers, or application Mappers.29- Do not query or persist directly; use Repository or Unit of Work contracts.30- Do not invent permissions, billing, sensitive-data, tenant, or lifecycle behavior.3132Finish only when business rules are traceable, dependencies are explicit, Service tests are persistence-free, and no HTTP or ORM coupling remains.
viniciusjsdev