ddd-angularlisted

# DDD in Angular Structure an **Angular** app around a domain. Start with the honest part below — DDD on the frontend is *adapted*, not the same as on the backend — then apply the structure and the idioms in the references. This is an **opinionated** house style: for every decision it names one convention and says what that convention buys, rather than listing options. It is one coherent way to do this, not the only correct one; where a choice is genuinely open, the reference says so. Examples use the **QuickBite** food-delivery domain, in an `ordering` bounded context. The idioms are standalone components, signals, and `inject()`. They work unchanged across current Angular versions; newer releases add alternatives — Signal Forms, signal-native data fetching with `httpResource()`, and the `@Service()` decorator as a shorthand for `@Injectable({ providedIn: 'root' })` — that you can adopt without changing anything about the structure here. One caveat, because it bites exactly one class in this skill: `@Service()` supports **only** `inject()`, never constructor injection, so a context API written as `constructor(http: HttpClient)` stays on `@Injectable`. See [house-style.md](references/house-style.md). ## What DDD means on the frontend The backend is the **system of record**: it owns the business rules, the invariants, and the transactional consistency. The frontend cannot enforce those — a determined user can bypass any client-side check — so it should not pretend to. Wh