Domain Driven Design
Domain-Driven Design (DDD) is a software development approach that emphasizes the importance of a deep understanding of the problem domain, its complexities, and its language. It was introduced by Eric Evans in his book “Domain-Driven Design: Tackling Complexity in the Heart of Software” (2003). DDD focuses on collaboration between technical experts and domain experts to create a shared understanding of the domain and its business rules.
| Key Concept | Description |
|---|---|
| Ubiquitous Language | A common vocabulary shared by domain experts and developers, ensuring clear communication and a shared understanding of the domain. |
| Bounded Context | A logical boundary that encapsulates a specific domain model, its logic, and its language, allowing for modular and maintainable development. |
| Entities | Objects with a unique identity that represent important concepts in the domain. |
| Value Objects | Immutable objects that describe attributes or properties of entities, without a unique identity. |
| Aggregates | A collection of related entities and value objects that act as a single unit, with a defined consistency boundary. |
| Repositories | Abstractions for persisting and retrieving aggregates, decoupling the domain model from the underlying data storage mechanism. |
| Domain Events | Notifications representing important occurrences in the domain, allowing for reactive and event-driven architectures. |
| Domain Services | Stateless operations that represent domain-specific business logic that does not fit within entities or value objects. |
DDD helps in building maintainable, scalable, and flexible software systems by putting the problem domain at the center of the development process.