domain-driven-design

Domain-Driven Design

Review the domain shape of a change through the lenses from Learning Domain-Driven Design (Vlad Khononov, O'Reilly). DDD works at two altitudes that compose:

• Strategic (Parts I, III–IV) — where the boundaries are: bounded contexts, ubiquitous language, and how contexts integrate.
• Tactical (Parts II–III) — how one context is built: the business-logic pattern, and whether aggregates/value-objects hold their invariants and publish events safely.

This is not a generic layering/cohesion check or trade-off/connascence audit (use architecture-lens), not macro style selection or service decomposition (use macro-architecture), and not a bug hunt (use code-review).

Select the review

Change	Read
Moves or crosses a bounded context, changes business naming, or integrates another system	references/strategic-review.md
Structures business logic, aggregates, value objects, or domain events inside one context	references/tactical-review.md
Does both	Strategic review first, then the affected tactical rules; boundaries constrain the internal design

Apply only the relevant lenses. Report findings with file and line, the rule, and a proposed fix. A clean lens needs no invented finding.

Deriving the context map: the physical bounded contexts are usually the backend services/modules, each owning a model and a slice of the ubiquitous language (e.g. a transactional core service, an integration/sync service, an event worker, a shared kernel of domain entities, the frontend's own API-layer model). Derive this map from the repo's service/module layout before reviewing. A subdomain is a problem area (pricing, dispatch, compliance); a bounded context is the solution boundary where one model/language holds — they often align but not always.

Evidence and output

The selected method contains its standalone output format. Lead with the highest-impact finding and distinguish evidence from an unresolved domain decision.

Under design-gate, remain read-only and use the caller's canonical gate result. Preserve actual invariants and integration boundaries; cosmetic preferences are advisory.

Detailed references

• references/context-patterns.md: load before classifying a context relationship or when the finding needs its full definition.
• references/decision-trees.md: load for borderline pattern classification or in-depth aggregate, value-object, and event checks.

In an interview, contribute the decision, rationale, constraints, and source references to the existing decision record. Standalone report and implementation mechanics do not apply at that stage.