Domain modeling

Put each business rule in one place that every path must go through, and draw boundaries where the language and the rules change. The patterns below are tools, not a template: a settings screen stays simple CRUD, an ordering or billing flow earns the full model. Pick the file:

Apply only the routes and checks for the selected job. Read a linked skill's named file from its installed folder when available, or from the linked source. Report an unavailable required reference instead of inventing it. [skill-authoring, DISTRIBUTION.md#composing-skills]

For reshaping existing code in small safe steps, also use the refactoring skill; for typed errors, its ERRORS.md.

Domain modeling is a set of patterns, not a framework: plain TypeScript types, functions and classes are enough. It's also not the same thing as Clean Architecture: Clean Architecture organizes which layers may depend on which; domain modeling decides what the innermost layer contains. They combine well, with the domain model at the center depending on nothing.

The building blocks, for orientation: entity (identity and lifecycle), value object (defined by its values), aggregate (consistency boundary with a root), domain event (a fact that happened), domain service (a rule that fits no single entity), repository (loads and saves an aggregate), factory (valid creation), specification (a named, reusable query or selection rule such as premiumCustomers, worth an abstraction only when the same criteria are reused in several places). Use the ones the rules call for, not all of them.