domain-driven-design

Choose an entity when identity matters and the object has a lifecycle; choose a value object when only its attributes matter. Value objects are immutable and compared by attribute equality, while entities are compared by ID. Prefer value objects over primitives for domain concepts like Money or Address.

Design small aggregates, each with one aggregate root that enforces true transactional invariants. Reference other aggregates by identity rather than object reference, and update only one aggregate per transaction, using domain events and eventual consistency for cross-aggregate changes.

A bounded context is an explicit boundary within which a particular model and ubiquitous language apply consistently. The same term can mean different things in different contexts, and integration across boundaries requires explicit translation such as an anticorruption layer or a published language.

Avoid DDD when the domain is shallow CRUD over a small data model, the application is a thin database wrapper, the team lacks access to domain experts, or the team is too small to absorb the overhead. Reserve DDD for the core domain where business complexity justifies careful modeling.

Yes. DDD assumes a layered architecture where dependencies flow inward and the domain layer depends on nothing technical, and it is compatible with hexagonal, onion, and clean architectures. Bounded contexts often align with teams or deployment units, making them natural microservice boundaries.

An anemic domain model reduces entities to getters and setters while pushing all logic into services, turning the model into a data structure rather than a domain model. Behavior should live on entities and value objects, with domain services reserved for operations spanning multiple objects.