Domain driven design (DDD) is a methodology for designing software with a focus on the domain. DDD is one of the main practices used in the microservices development. I'll cover 3 main concepts of the DDD:
- Ubiquitous Language - use the same language/terms in the code and in the business. This allows programmers to talk to the business people without misinterpretation.
- Aggregate - Related objects, that form a consistency boundary and are treated as a single unit. For example in the "Customer" domain, "Address" is an aggregate.
An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary. The boundary defines what is inside the aggregate. The root is a single, specific ENTITY contained in the aggregate.
Domain Driven Design, Eric Evans
- Bounded Context - a logical and physical boundary around a coherent and consistent domain or subdomain
What if you already have a domain and want to slice it to migrate from the monolith to the microservices, for example? You can do this using these patterns:
- Volatility - split by the performance sensitive parts
- Data - split by usage or restrictions on the data
- Technology - split by a technology stack
- Organizational - align with the company organizational structure
Microservices, 2nd edition by Sam Newman