ddd-reactlisted

Structure a React frontend with Domain-Driven Design — bounded-context feature folders, a domain layer of immutable entity and command classes that carry behaviour, assemblers as an anti-corruption layer against the backend API, Zustand stores, and a presentation layer of routed views and reusable components. Use when organizing or refactoring a React app by business domain rather than by technical type, isolating API payloads from the app's own model, or deciding where business logic belongs on the frontend. It carries the DDD design rules it depends on, so it works on its own. Not for styling, React framework how-to, or backend domain modeling.
salimramirez/agent-skills · ★ 4 · Web & Frontend · score 78

Install: claude install-skill salimramirez/agent-skills

# DDD in React Structure a **React** 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 stack is **React with TypeScript, React Router, Zustand and axios**, built with Vite, for a client-rendered SPA. `javascript.md` covers what changes if your project is JavaScript. > **Where this comes from.** Its siblings `ddd-angular` and `ddd-vue` mirror real codebases. This one does not: it **derives** the same four-layer model onto React, and every framework-specific claim in it was checked by building and running a real app rather than by reasoning. Where React genuinely differs, the reference says what was measured. Treat the DDD structure as settled and the React mechanics as a well-tested opinion. ## 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. What the frontend *does* gain fr