Domain Driven Design(DDD) in terms of Microservices.
- Domain Driven Design (DDD) is about mapping business domain
concepts into software artifacts. These writings discuss the main
elements of DDD such as Entity, Value Object, Service etc
- Microservices have a symbiotic relationship with domain-driven
design (DDD) a design approach where the business domain is
carefully modeled in software and evolved over time.
- Microservices primary focus on the core domain, domain logic
Keep the microservice context boundaries relatively small
- Initially create the smallest possible microservices, although
that should not be the main driver. Create a boundary around things
that need cohesion.
- Avoid more/expansive communications between microservices
- Cohesion is key within a single bounded context
Layers in DDD microservices
- Enterprise applications with significant business and technical
complexity are defined by multiple layers. Create the logical
artifact for layer and are not related to the deployment of the
- Domain entity is contained within the domain model layer and
should not be propagated to other areas that it does not belong to
like to the presentation layer.
- Entities should not be bound to client views because at the UI
level some data might still not be validated.
- The domain entities do not belong directly to the ViewModel.
Data flow/translate between ViewModels and domain entities and vice
versa. e.g. Ordering application
- The setting in which a word or statement appears that determines
its meaning i.e. related to domain names.