DDD Microservices

Domain Driven Design Infrastructure

Before DDD it was common practice to attempt to find a model that spanned the complete domain. The problem is that the larger the domain, the more difficult it is to find a consistent and unified model. DDD’s solution is to identify bounded contexts so that the domain can be broken down into manageable subdomains.

Microservices and Domain Driven Design

Microservices architecture complements DDD by offering a scalable and flexible way to implement domain models as independent services. Each microservice focuses on a specific business capability or bounded context, allowing teams to develop, deploy, and scale services autonomously.

When using microservices each one must correspond to a bounded context within its own domain model. By breaking the services down into microservices each bounded context is manageable from

An important piece of architecting a domain driven design system is deciding how bounded contexts will communicate. There are four main types of relationships.

• Open Host Service (OHS): the service provider defines an open protocol for others to consume. This is an open-ended relationship, as it is up to the consumers to conform to the protocol.
• Published Language (PL): this relationship uses a well-known language such as XML, JSON, GraphQL, or any other fit for the domain. This type of relationship can be combined with OHS.
• Anticorruption Layer (ACL): this is a defensive mechanism for service consumers. The anti-corruption layer is an abstraction and translation wrapping layer implemented in front of a downstream service. When something changes upstream, the consumer service only needs to update the ACL.
• Separate ways: this happens when integration between two services is found, upon further analysis, to be of little value. This is the opposite of a relationship — it means that the BCs have no connection and do not need to interact.