Domain-Driven Design (DDD) is an approach to designing software systems that focuses on the domain and its logic. DDD breaks down complex domains into related but independent bounded contexts. Within each context, a specific language (Ubiquitous Language) is developed in agreement with domain experts. The main building blocks of DDD include:
Bounded contexts often represent separate microservices that interact through explicitly defined APIs or events.
Java code example (Spring):
// Example of Value Object @Embeddable public class Address { private String city; private String street; // ... constructors, equals, hashCode } // Example of Entity with Aggregate Root @Entity public class Order { @Id private Long id; @Embedded private Address deliveryAddress; // ... business methods }
Key features:
Are all objects in DDD Entities?
No, there are also Value Objects — they do not have uniqueness, and their state fully determines their identity.
Address a1 = new Address("Moscow", "Arbat"); Address a2 = new Address("Moscow", "Arbat"); System.out.println(a1.equals(a2)); // true
Does breaking into microservices mean applying DDD?
No, DDD can also be applied within a monolithic application by establishing internal bounded contexts.
Is a repository always needed for each aggregate?
Usually yes, but sometimes an aggregate can be fully stored as part of another aggregate if it is not the root of a separate business transaction.