rules-architecturelisted

## Positioning Jardis treats DDD as **vocabulary**, not orthodoxy. It sits **closer to Functional DDD (Wlaschin) than to Rich Domain Model (Evans)**: entities and value objects hold data, behaviour lives in Actions, Commands, Queries, Domain Services — never as methods on entities. Invariants are enforced by the pipeline, not by entity guards. This is **why** the five pillars below take the shape they do — particularly Data-Behavior Separation (§1.4) and Composition over Inheritance (§1.3). Implementation skills (`platform-implementation`, `platform-usage`) extend this stance into the Designer-generated layer. ## Scope Applies to Jardis packages (`JardisAdapter/*`, `JardisSupport/*`, `JardisTools/*`) and library code inside the hexagonal cake. The five pillars (§1) also hold on the Designer-generated Domain layer, but the physical directory contract there is different — see `platform-implementation`. ### 1. Five pillars 1. **Separation of Concerns** — different responsibilities → different components. Cross-cutting via Decorator/Middleware. 2. **Single Responsibility** — one class = one reason to change. "And"-test: description contains "and" → split. 3. **Composition over Inheritance** — interfaces, Constructor Injection, runtime replaceability. **No traits.** `abstract` only for Exception hierarchies. `static` only for VO named constructors. 4. **Data-Behavior Separation** — DTOs / Entities / VOs hold data. Services operate on data. Persistence external via Repository.