domain-modeling
Domain Modeling for PHP Apps
When to Use (and When NOT to)
DDD adds ceremony that must justify its cost. Use DDD when the project has a complex business domain with many rules and will be maintained for years by a team. Skip DDD for prototyping, MVPs, solo-developer projects, or simple CRUD with few business rules.
| Use DDD For | Use Simpler Patterns For |
|---|---|
| Complex business domain with many invariants | Simple CRUD, few business rules |
| Long-lived system (years of maintenance) | Prototype, MVP, throwaway code |
| Team of multiple developers | Solo developer or tiny team (1-2) |
| Multiple entry points (API, CLI, events) | Single entry point, simple API |
| Need to swap infrastructure (DB, broker) | Fixed infrastructure, unlikely to change |
| High test coverage required | Quick scripts, internal tools |
Start simple. Evolve complexity only when needed. Most systems do not need full DDD. For libraries, packages, or SDKs that have no user-facing behavior, plain PSR-4 classes with clear names are usually sufficient. For simple CRUD, lean ORM entities are preferable to rich domain objects.
Note: the choices below (Transaction Script, Table Module, Domain Model) are about how business rules are organized. The Application (or Service) Layer sits above this spectrum — it defines the application's boundary and coordinates whichever domain-logic style you pick. See the application-layer skill for Service Layer definition and the overuse anti-pattern (Controller → Service → Repository → Entity with an anemic domain).