Ddd Angular

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.

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 from DDD is structure: organizing the app by the domain (not by technical type), speaking the same ubiquitous language as the backend and the experts, keeping a client-side model of the domain separate from the UI, and pushing logic out of components. So treat what follows as DDD-inspired organization, not as a place to re-enforce business rules.

The rules below are Domain-Driven Design in general, written for a model that owns its data. A client model does not, so some of them arrive intact, some loosen, and a few do not apply at all — the section immediately after the block says which is which. Read the two together.

Prime directive: model the domain, and protect it

• Put business rules and invariants inside the domain model itself, not scattered across controllers, services, or SQL. A model that only holds data while the logic lives elsewhere is an anemic domain model — the most common DDD failure, and the main thing DDD exists to prevent.
• Speak the ubiquitous language: use the exact terms domain experts use, in the code (class, method, variable names) and in conversation. If the business says "policy", the class is Policy, not InsuranceRecord. A gap between code and language is a defect waiting to happen.
• Keep the domain pure: the domain layer expresses business concepts and must not depend on frameworks, persistence, web, or messaging concerns. Those belong at the edges.

Layered architecture (4 layers)

Organize code into four layers. Dependencies point inward, toward the domain; the domain depends on nothing outside itself.

1. Interfaces — the inbound adaptors: entry points where the outside world drives the context (REST/GraphQL controllers, CLI, message/event listeners, schedulers). Translate external input into application calls and the result back out. No business logic.
2. Application — orchestrates use cases (application services, often split into command services and query services): loads aggregates, invokes domain behavior, manages transactions and security. Coordinates, but holds no business rules itself.
3. Domain — the heart: entities, value objects, aggregates, domain events, domain services, and the repository and service interfaces (ports). All business rules and invariants live here. Depends on nothing but itself.
4. Infrastructure — the outbound adaptors: the technical implementations the context uses to reach the outside (persistence/ORM and repository implementations, messaging, external API clients). Implements the ports the inner layers declare.

The inner layers declare ports (interfaces) and the adaptors implement them — an inbound adaptor brings a request into the context, an outbound adaptor lets it reach out. This is the classic DDD layered model; it does not require hexagonal, onion, or "clean" architecture — those are compatible refinements, but the non-negotiables are domain purity and the inward dependency rule.

Bounded contexts

A bounded context is an explicit boundary within which a model and its ubiquitous language stay consistent. The same word can mean different things in different contexts (a "Customer" in Sales ≠ in Support); don't force one model across the whole system.

Tactical building blocks — how to decide

When modeling, choose the right block deliberately:

• Value Object — no identity; defined entirely by its attributes; immutable. Use liberally: money, date ranges, addresses, quantities, identifiers. Prefer a value object over a primitive whenever a concept carries rules (e.g., Money bundles amount + currency and forbids mixing currencies). They make invalid states unrepresentable.
• Entity — has a distinct identity that persists through changes to its attributes (a Customer stays the same customer even if their name changes). Use when identity and a lifecycle matter.
• Aggregate — a cluster of entities and value objects treated as one consistency unit, accessed only through its aggregate root. Key rules, each with a reason:
  • Keep aggregates small — large ones cause contention and load too much data.
  • One aggregate = one transaction. Don't modify two aggregates in the same transaction; it couples their consistency.
  • Reference other aggregates by identity (ID), never by holding their object — this keeps boundaries and transactions clean.
  • Enforce the aggregate's invariants inside the root, so it is always internally consistent.
• Domain Event — a statement that something meaningful happened in the domain (e.g., OrderPlaced). Use it to achieve eventual consistency across aggregates and to decouple side effects from the action that caused them.
• Domain Service — stateless domain logic that doesn't naturally belong to a single entity or value object (e.g., a transfer between two accounts). Keep it in the domain layer; don't confuse it with an application service.
• Repository — collection-like access to aggregates by their root. Define one repository per aggregate root, with the interface in the domain layer and the implementation in infrastructure.
• Factory — encapsulates complex creation of an aggregate or value object when a plain constructor would be unclear or would leak rules.

CQRS

Command Query Responsibility Segregation separates the model that changes state (commands) from the model that reads it (queries). It comes in two strengths, and conflating them is a common source of over-engineering:

• The light form — split the application layer along the command/query line (command services and query services). One model, one store, no eventual consistency. It is cheap, it keeps write orchestration from tangling with read orchestration, and it is a reasonable default.
• The full form — give each side its own model: a write model (the aggregates, enforcing invariants) and a separate read model shaped for how the data is queried, kept up to date from domain events. It buys queries that span aggregates and independent scaling; it costs projection machinery and eventual consistency. Treat it as a deliberate choice per bounded context, not a default.

How to approach a DDD task

1. Establish the language — clarify the domain terms with the user; use them verbatim in the model.
2. Locate the bounded context — which context are we in, and what is its model?
3. Find the aggregates and their invariants — what must always be true, and what is the consistency boundary?
4. Model tactically — choose value objects, entities, and aggregate roots; push rules into them; keep the domain pure.
5. Place each piece in the right layer — rules in domain, orchestration in application, I/O in interfaces, technical detail in infrastructure.
6. Implement for the stack — follow the stack's implementation idioms; see the routing below.

What carries over, loosens, or doesn't apply

• Carries over: the ubiquitous language; bounded contexts; the four-layer split with an isolated domain; anti-corruption via assemblers; keeping logic out of the UI.
• Loosens: repositories are API endpoints rather than aggregate stores, so the repository interface the core puts in the domain layer has no counterpart here; aggregates and value objects are lighter or skipped (the UI rarely needs them); "domain events" are usually signal updates rather than published events.
• Doesn't apply: three of the core's rules are about a model that owns its data, and a client's does not.
  • Enforcing invariants inside the aggregate root. The server enforces them; a client-side check is UX, and the server validates again.
  • One aggregate, one transaction. There are no transactions here. What the core is protecting — consistency — is the server's to protect.
  • The anemic-model test. It asks whether a model that owns its data has let its rules leak elsewhere. A client model is a projection of a model that lives elsewhere, so it cannot fail that test, and there is no rule here about entities having to protect themselves. Put a method on an entity when it stops an expression being repeated across views, not out of duty.

The house style in one screen

The rules this skill applies by default. Each one is expanded, with its reason, in the reference that owns it.

• A bounded context is a feature folder under src/app/, with domain/, application/, infrastructure/, and presentation/ inside it. shared/ is the kernel and stays small.
• One store per context, named after the context (OrderingStore), not per entity and not one for the app.
• The store is the only thing that calls the context API; only an endpoint touches HttpClient. A view calls its store, and that is the whole chain.
• Entities are classes in *.entity.ts — private fields, accessors, one options-object constructor, implements BaseEntity. A setter exists only where the UI genuinely changes the value.
• Other aggregates are referenced by id. A resolved object is stitched in by the store, and the id stays the source of truth.
• The resource never leaves infrastructure/. Assemblers are the anti-corruption layer; a snake_case field in a template means one was skipped.
• CRUD writes send the entity; everything else sends a command. A command is a class with no id, and it travels through its own request DTO.
• State is private signals published read-only, with computed() for anything derived. Reads use takeUntilDestroyed, writes use retry(2), and every call sets loading and clears it in both branches.
• Views are smart and routed; components are dumb and reusable — input() in, output() out, and a dumb component never sees the store.
• Every context owns its routes and lazy-loads its views; the root router mounts contexts with loadChildren.
• URLs are composed from environment, one base URL per provider plus one path per endpoint — never a literal in an endpoint.
• Classes, interfaces, and public methods carry JSDoc. The domain layer is where the ubiquitous language gets written down.

Implementation references

Read the file that matches the task at hand.

Starting a piece of work

• Adding a resource end to end — the nine files in order, plus the checklist to finish on. Start here for "add X to the app". Read adding-a-resource.md
• Folder structure, naming, and environment — contexts and layers, the file-to-class naming table, and where URLs come from. Read structure.md
• House style — the JSDoc rule, member ordering, and the layer smells to avoid. Read house-style.md
• The shared kernel — the seven base classes every context builds on. Read shared-kernel.md

Modeling the domain

• Entities and commands — entities as classes with accessors, value objects, and commands for non-CRUD intents. Read domain-model.md

Talking to the backend

• The CRUD path — DTOs, assemblers, endpoints, and the context API. Read infrastructure.md
• Commands and actions — the non-CRUD path, and integrating an API that is not yours. Read commands-and-actions.md

Holding state

• The signal store — signals and computed queries, loading and error handling, stitching, and caching. Read state-store.md

Building the UI

• Views, components, and routing — the smart/dumb split, per-context lazy routes, and the app shell. Read presentation.md
• Reactive forms and writes — one view for create and edit, validation as UX, entity or command. Read forms.md
• Cross-cutting concerns — guards and interceptors in the context that owns the rule, localization, and app bootstrap. Read cross-cutting.md

Copy instead of retyping

Two things ship as code, because they should come out the same every time.

Run both commands from the root of the Angular app, with $SKILL pointing at the directory this skill was installed into — .claude/skills/ddd-angular in a standard install:

SKILL=.claude/skills/ddd-angular

• assets/shared-kernel/ — the seven base files, already laid out in the layers they belong to. Copy the folder's contents into src/app/shared/ and they land where their imports expect:

  cp -R "$SKILL/assets/shared-kernel/" src/app/shared/
  

  Do not paraphrase them from the docs, and do not flatten them — base-assembler and base-api-endpoint reach base-entity through ../domain/model/.

• scripts/new-context.py — scaffolds a whole bounded context wired for one CRUD aggregate, deriving every spelling of the name from two arguments:

  python3 "$SKILL/scripts/new-context.py" --context ordering --entity Order --into src/app
  

  --into is resolved against the current directory, so run this from the app root, not from the skill folder. Add --dry-run to see what it would write, --plural People when the naive plural is wrong. It prints the two edits it cannot make for you: the environment keys and the route in app.routes.ts. What it writes is ordinary code — read it, then model the real aggregate.

For Angular questions the references do not cover, read the documentation at https://angular.dev.

For the strategic side — discovering the domain, finding bounded contexts, EventStorming, context mapping — use the ddd-playbook skill. For the backend that owns the invariants, use ddd-spring-boot.