Domain Driven design originates from a book called Domain Driven Designby Eric Evans. One of the key goals of the book is to try to create a software implementation that is based on an evolving model that is understood by the domain experts. so largely about creating a communication channel between the domain experts and the software developers. As far as goals go for domain driven design one of the key goals within it is to take a large system, or a large domain and to break it down to smaller pieces. the problem that we have the larger domain you have the more harder you can deal with it and harder to model a a large singe coherent model. break things down into small pieces. this gives us a way to determine the boundaries, essentially between those smaller pieces within the larger domain,
Reactive micro-services for example have a similar goal they need to be separated along clear boundaries, each microservice has to have a clearly defined api and a specific set of responsibilities. if we don’t know what the responsibilities of the microservice it’s going to be very hard to build it and have a proper design for it. That is where the DDD will help us it gives us a set of guidelines and a set of techniques that we can use to try to help us to break larger domains into a smaller ones.
Decomposing the domain
- take the large domain and separate them into subdomains, our subdomains are created by grouping related ideas and actions and rules into separate domains.
- because of that each subdomain essentially ends up having its own ubiquitous language and model. The language and model for a subdomain is what we call a bounded context,** subdomain or Bounded contexts are good starting points for building reactive microservices.
- from one Bounded context to the next the meaning of a word may change dramatically.
- in restaurant, when talking to a server, an order, has a very specific meaning.
- when we speaking to the person who manage inventory for the restaurant order means something completely different.
How to determine bounded context
- here you are some guidelines because there are no universal answer
- consider human culture and interaction
- Different areas of the domain that are handled by different groups of people, suggests a natural division.
- look for changes in ubiquitous language
- if the use of language or the meaning of that language changes, that may suggest a new context.
- look for varying or unnecessary information
- employee id is very important in an employee, meaningless in a customer.
- strongly separated bounded context will result in smooth workflows.
- an awkward workflow may signal a misunderstanding of the domain.
- if a bounded context has too many dependencies it may be overcomplicated.
Event First Domain Driven Design
-
Traditionally DDD focused on the objects within the domain
- Cook, Reservation, Customer…
-
Event First Domain Driven Design Places the focus on the activities or events that occur in the domain
- customer makes a reservation, server places an order, food is served to the customer.
- using event first DDD we start by defining the activities, then group those activities to find logical system boundaries
Maintaining purity of boundaries
Maintaining the purity of those bounded contexts needs a technique or a set of techniques that allows us to do that.
Anti-Corruption Layers
Each Bounded context may have domain concepts that are unique, Concepts are not always compatible from one context to the next.
- Anti-corruption layers are introduced to translate these concepts
- Anti-corruption layers will prevent Bounded context from leaking into each other.
- Anti-corruption layers help the bounded context to stand alone.
How Anti Corruption Layers are implemented
a common way to build it is abstract interface that represent pure domain representation of the data and then we have implementation of this interface which dose that translation and that sort of infrastructure component that dose that translation.
Anti-Corruption Layers for Legacy systems
the domain for the legacy system maybe messy or unclear, but the Anti-Corruption layer keeps your Bounded Context pure. It prevents your domain from dealing with the mess of the legacy system.
Context Maps
- Context Maps are a way of visualizing Bounded Contexts and the relationships between them.
- Bounded Contexts are drawn as simple shapes
- lines connect the Bounded Contexts to indicate relationships
- Lines may be labeled to indicate the nature of the relationships