Glossary · Software Architecture
What is domain-driven design (DDD)?
Short answer
Domain-driven design (DDD) is an approach to building complex software in which the code is modelled closely on the business domain. Developers and domain experts agree on a shared vocabulary (the ubiquitous language), split the system into bounded contexts with clear boundaries, and keep business rules inside domain objects rather than spreading them across controllers and SQL.
Key ideas
- Ubiquitous language: the same words in conversations, tickets and code. If the business says “policy holder”, the class is
PolicyHolder, notUser. - Bounded contexts: a “product” means different things to catalogue, warehouse and billing. Each context gets its own model and owns its data.
- Entities and value objects: entities have identity (an order); value objects are defined by their values (money, an address) and are immutable.
- Aggregates: clusters of objects changed together through one root, which protects the business rules, for example “an order cannot ship without payment”.
- Domain events: records of things that happened, such as
OrderShipped, used to notify other contexts.
When it is worth it
DDD pays off where business rules are complex and change often: insurance, logistics, finance, healthcare. For simple CRUD screens it adds ceremony without much benefit.
In PHP
Laravel and Symfony both work well with DDD: keep domain classes free of framework code, use PHP 8 readonly classes and enums for value objects, and map them to the database in an infrastructure layer. Bounded contexts are also the natural seams when splitting a monolith into microservices.
