domain-driven-design

Apply Eric Evans' Domain-Driven Design when modeling a business domain — ubiquitous language, bounded contexts, entities vs value objects, aggregate boundaries, repositories, factories, specifications, and anti-corruption layers. Use when naming domain concepts, deciding whether something is an entity or a value object, drawing aggregate or transaction boundaries, integrating with another system's model, replacing primitives that carry business meaning, extracting rules from repeated conditionals, or reviewing code for a passive/anemic domain model. Do not use for CRUD-only supporting subdomains, technical infrastructure with no business rules, or codebases where the domain is genuinely trivial.