Whetstone.
DDD from zero, in a language you knowThe Nest/Next reflexes that read as slop
Module 1 · Lesson 612 min

The Nest/Next reflexes that read as slop

You’ve got the concepts. Before the course drops into real Fusion code, here’s the practical map: the specific Nest and Next reflexes you carry, how each one reads to a Fusion reviewer, and where the course fixes it properly. Naming them now means you’ll feel the reflex before it reaches the diff.

Every row here is one of the concepts you just learned, in its “bad habit” form. This lesson isn’t new material, it’s the translation table between how you’d instinctively write something and what the team expects.

Reflex → how it reads in Fusion → the fix (taught later)
throwthenBadRequestExceptions for invalid input → return Result<T> (Module 2)
FooServiceGod-class with all the logic → behaviour on the domain object; no Service/Manager/Provider (Modules 4-5)
newthenEntity()Public ctor + set fields → private ctor + static Create → Result (Module 3)
validate()Validate in a service before the entity → validation lives INSIDE the domain action (Module 4)
onethenrepoOne repository reads and writes → CQRS split: QueryStore reads, Repository writes (Module 6)
DTOthenmapMap at every layer → each representation needs a unique use case (Module 6-7)

The word that ties it together is the one from Lesson 4: anaemic domain model. Objects that are just public fields with no behaviour, where all the real logic sits in a separate service that operates on them. It’s the default shape in a lot of TypeScript backends (a class-validator DTO plus a service). In DDD it’s the primary smell, and Fusion review will name it. Most of the “slop” you’ll ever be flagged for is some flavour of this: the logic ended up in the wrong place, off the model.

From here the course gets concrete. Module 2 is the Result<T> machinery for errors-as-values. Module 3 is the private-ctor value object. Modules 4 and 5 are entities, aggregates, and the layering. Modules 6 and 7 are the application and persistence mechanics. Then “Decode your own reviews” walks the real comments you got, so the concepts you just learned in the abstract land against the exact moment a reviewer taught you each one. Same ideas, three passes: concept, mechanism, lived feedback.

Practice

Try it yourself

Quiz

Match the reflex to the fix

You instinctively reach for a FooService to hold your feature's logic. What's the DDD fix?

  1. APut the behaviour on the domain object; there is no Service/Manager/Provider
  2. BRename it FooManager
  3. CSplit it into FooReadService and FooWriteService classes
  4. DMake it a static class
Show answer

Correct answer: A — Put the behaviour on the domain object; there is no Service/Manager/Provider

The fix isn't a better name for the service, it's to move the behaviour ONTO the domain object and shrink the orchestration to a verb-named use case. Fusion bans Service/Manager/Provider as class names precisely because they attract the anaemic god-class shape.

Recall

Which way does logic move

State the core shift in one sentence.

Compared to a typical Nest/Next backend, which direction does domain logic move in DDD, and onto what?

Reveal answer

It moves inward: out of services and DTOs, onto the domain objects themselves. The value object validates itself, the aggregate owns its invariants, and the service layer shrinks to orchestration.

Sign in to track your progress →