Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-ddd-tactical
Tactical DDD — aggregate design rules, entities, value objects, domain events, repositories, domain services, and anti-pattern detection
Passed 22 of 23 test cases with the skill, and 21 of 23 without it.
1 fixed21 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
In an e-commerce shipping context, we treat Address as an immutable Value Object with no lifecycle identity. However, in a municipal property tax context where a location has historical tax records, structural inspections, and changes ownership over 50 years, should Address remain a Value Object?
| Checked | Without skill | With skill |
|---|---|---|
| Address is modeled as an Entity in the tax context because it possesses persistent identity and lifecycle. | Missed | Passed |
The instructions your model reads when the skill loads.
Implementation patterns within a bounded context. Tactical DDD answers: "How do we structure the domain model?"
An aggregate is a consistency boundary -- a cluster of domain objects that must be transactionally consistent.
Model true invariants in consistency boundaries: Only include elements that MUST be consistent within the same transaction. If two entities don't share an invariant, they belong in separate aggregates.
Design small aggregates: ~70% of aggregates contain only a root entity with value-typed properties. Large aggregates create concurrency contention, scalability failures, and memory pressure.
Reference other aggregates by identity: Use ProductId not Product. Direct object references create accidental cross-aggregate transactions and prevent independent scaling.
Use eventual consistency outside the boundary: Domain events communicate across aggregates. One transaction = one aggregate. If you need to update two aggregates "atomically," reconsider your boundaries.
| Smell | Signal | Fix |
|---|---|---|
| God Aggregate | >5 entities, frequent concurrency conflicts | Split by invariant analysis |
| Anemic Aggregate | All logic in services, aggregate = data bag | Move business rules into aggregate methods |
| Cross-Aggregate Transaction | Two aggregates modified in one DB transaction | Use domain events + eventual consistency |
| Deep Nesting | Aggregate root -> entity -> entity -> value | Flatten; promote nested entities to own aggregates |
| Missing Aggregate | Business rules scattered in application services | Identify invariant cluster, create aggregate |
Objects with identity that persists across state changes. An entity is the "same" entity even when all its attributes change (a person who changes name, address, and job is still the same person).
test cases passed, vs 21 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.