Domain-driven design

In short: Domain-driven design (DDD) aligns software with the business domain. Developers and domain experts develop a shared language, and the code mirrors the domain terms.

In more detail: Large systems are split into “bounded contexts” in which every term has a clear meaning (“customer” in sales differs from accounting). Inside a context you model with entities, value objects and aggregates.

In Depth

• Ubiquitous language: One shared domain language in conversations and code.
• Bounded context: Boundary in which a model applies. Often matches a microservice.
• Entity: Has identity (for example customer no. 42). Value object: Defined only by values (for example an amount of money), immutable.
• Aggregate: Group of objects with a root that ensures consistency.
• Domain events: Important events of the domain.
• Context map: Relationships between contexts (anti-corruption layer, shared kernel).
• When: Complex business logic. For simple CRUD it is too much.

See also: Hexagonal architecture, Event sourcing and CQRS