Domain Driven Design
Pioneered by Eric Evans and introduced to the world in his book “Domain-Driven Design: Tackling Complexity in the Heart of Software.”, Domain Driven Design or DDD is a design technique for software systems.
Core Elements of DDD
The Ubiquitous Language
A common shared language used by everyone, whether they're technical or non-technical. We talk about things in the same way in order to communicate with precision and clarity, not because we enjoy looking like comic book guy ;-)
"Worst blog...ever"
Bounded Contexts
We use decomposition to break up a complex domain into sub-domains with clear boundaries so each sub-domain can have it's own rules and ubiquitous language if needed. We can communicate and interact across boundaries using well defined APIs or events.
Entities
Object's which are defined by their identity
Value Objects
The attributes of a value object are what define it. Usually Immutable.
Aggregates
We can use composition to create aggregates of related entities and value objects. The class we compose these related items into is typically referred to as the aggregate root.
Repositories
This is what we call our persistence abstraction.
Domain Services
Large chunks of logic related to our domain that can involve the interaction of multiple objects.
Factories
Creational design patterns for encapsulation and valid construction.
Domain Events
Events related to the domain e.g. New order event, market state changed event.
Anti-Corruption Layer
Translational layer between bounded contexts, external and legacy systems. The idea is to prevent pollution between your nice clean DDD code and legacy systems which may also use a different ubiquitous language if any.
Benefits of using DDD
- Seperation of business logic from infrastructure code
- Code should reflect the business domain
- Bounded contexts can grow independently so are less coupled
Links and Resources
https://martinfowler.com/bliki/DomainDrivenDesign.html - Martin Fowler on DDD
https://www.youtube.com/watch?v=lrSB9gEUJEQ - DDD and LLMs