dca-disciplinelisted

# /dca-discipline — DCA invariants while writing code This skill is a **set of write-time guards**, not a review. Before every edit inside a DCA-shaped project, Claude checks the file's layer and applies the rules that apply to that layer. ## The six invariants ### 1. No framework in domain Files under `**/domain/**` MUST NOT import: - `org.springframework.*` - `jakarta.persistence.*`, `jakarta.validation.*` (except Bean-Validation annotations only if the project deliberately allows it — check conventions) - `org.hibernate.*` - `com.fasterxml.jackson.*` - Any other framework-specific package C# (`**/Domain/**`): no `Microsoft.AspNetCore.*`, `Microsoft.EntityFrameworkCore.*`, `System.Data.*`, `System.Transactions.*`, `System.Text.Json.Serialization` attributes, `Microsoft.Extensions.*` — and no `async` member: ports are async, the domain is not. **What to do when the user asks for a forbidden import:** > The annotation `@Component` would put framework code into the domain. The > DCA invariant is: domain is framework-free. Place this class in > `application/{usecase}/` (if it's a use case) or in `adapter/` (if it > integrates with a framework). > > Want me to (a) move the class, or (b) keep it in domain *without* the > annotation, or (c) explicitly override the rule via an ADR? Don't silently rewrite; ask. The third option is rare but real — if the user chooses it, suggest `/adr new` to record the exception. ### 2. Dependency inversion Code in `domain/` and `applic