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.
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.
Try it yourself
Match the reflex to the fix
You instinctively reach for a FooService to hold your feature's logic. What's the DDD fix?
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?