domain-driven-design

Domain-Driven Design uses entities with identity-based equality and value objects with immutability to represent domain concepts. Entities track state changes over time; value objects remain immutable and are compared by their attributes, not identity. Together they form the foundation of a cohesive domain model.

Aggregates group related entities and value objects into transactional boundaries, ensuring consistency. Repositories abstract data access for aggregate roots, so your domain logic stays independent of storage implementation. This separation lets you swap databases without changing domain code.

Bounded contexts mark language and rule boundaries within a domain; context maps show how separate contexts relate and communicate. This prevents terminology collisions and clarifies integration points, especially critical in enterprise systems where teams work on different business areas.

Use DDD when your domain logic is genuinely complex—multiple business rules, changing requirements, or teams needing shared vocabulary across services. For simple CRUD operations or one-off scripts, DDD adds overhead without benefit. DDD pays off in long-lived systems where clarity and maintainability matter.

Domain events capture state changes within an aggregate and signal them to other parts of the system. This lets you maintain consistency between aggregates without direct coupling; other bounded contexts subscribe to events and react accordingly, keeping your architecture loosely integrated.

DDD defines domain structure independently; event sourcing stores state as event history, and CQRS separates read and write models. All three complement each other—DDD shapes your aggregate boundaries, event sourcing captures their history, and CQRS optimizes queries. They work best together in event-driven architectures.