What DDD is, and what "slop" means

You know how to build software. Coming into Fusion from NestJS, NextJS, and TypeScript, you have the skills. What you're missing is a specific idiom, and this course teaches it from the ground up: first the concepts in a language you already speak, then the exact dialect the Fusion backend is written in, then a walk through your own review comments so you can decode what the team was telling you.

Start with the idea itself. Domain-driven design is a way of structuring code so the business model sits at the centre. The objects in your code are the nouns and verbs of the business (a flight, a decision, "confirm", "revert"), and they carry the business rules themselves. The framework, the database, and the HTTP layer are wiring around that core, not the core. When it's done well, the code reads like the problem it solves, and whole categories of bug become unrepresentable rather than merely unlikely.

Here's the shape you're probably used to. In a Nest backend, a typical feature is a class-validator DTO (public fields plus decorators), a Service that holds all the logic, and a repository the service calls. The DTO is a data bag; the behaviour lives in the service. That works, and it ships, but it has a specific weakness: the data objects can hold any state at all, and the rule that they shouldn't lives somewhere else, in a service you have to remember to call.

DDD inverts that. The logic moves onto the domain objects. A value object validates itself at construction. An aggregate owns its own rules and won't let you break them. The service (in Fusion, a "use case") shrinks to orchestration: load the object, call one method on it, save. Same features, different centre of gravity.

That inversion is why "slop" comes up in review. When a Fusion reviewer calls a PR slop, they're rarely saying the logic is wrong. They're saying it's written in a shape the codebase doesn't use: an exception where the team returns a value, a Service class where the logic belongs on a domain object, a public field where the team makes invalid states impossible to construct. It's a shape mismatch, and the shape is a small set of concrete moves you can learn.

The rest of this module teaches those moves as pure concepts, each one anchored to something you already do in Nest/Next: ubiquitous language and bounded contexts, entities versus value objects, aggregates and the anaemic-domain trap, and errors as values. Then Modules 2 through 8 show the exact Fusion mechanics, against the real backend. Then the final content module walks the real comments you got on your own PRs and decodes each one. By the end, the blob in this course's capstone (a NoteService you'll recognise instantly) is something you can refactor into the Fusion shape without looking anything up.