Domain-Driven Design provides techniques to analyze a problem in a more manageable way. Therefore developers focus on the task, without worrying about all the other complexities surrounding it. We use Domain-Driven Design to facilitate communication between developers and domain experts.
What is Domain?
A Domain is a sphere of knowledge. In the context of software, it refers to the business or idea that we are modeling. Experts in the domain are people who understand the business, not necessarily the software.
The key goal of Domain-Driven Design is to build a model that the domain experts understand. Note – The model is not the software, the model represents our understanding of the domain and software is an implementation of the model. Communication between developers and domain experts requires a common language. The language is called the Ubiquitous language.
Decomposing the Domain
Business domains are often large and complicated. They contain many ideas, actions, and rules that interact in complex ways. Therefore trying to model a large domain can become problematic.
Subdomains
So what we do in domain-driven design is we take our large domains and we separate them into subdomains. Our subdomains will create by grouping related ideas and actions and rules into a separate subdomain. If we look at the Restaurant Domain example, we had all those different ideas but some of them are related. For instance, we can look at reservations: table, customer, time, location, those are all specifically related to creating a reservation.
Bounded Contetxts
Each subdomain has its own ubiquitous language and model. Bounded context is a combination of the Ubiquitous language and model for a subdomain. Subdomains or bounded contexts are good starting points for building reactive microservices.
Understanding Bounded Contexts
From one bounded context to the next the meaning of a word may change dramatically. In the restaurant, for instance, we’re talking to a server, the term order has a very specific meaning. In other words, when you talk to the server it means one thing. However, if you talk to somebody else in the restaurant, for example, the person who manages inventory, then order means something different. In other words, Strongly separated bounded contexts or microservice will result in smooth workflows.
Event First Domain Driven Design
- Traditionally, Domain Driven Design focused on the objects within the domain. E.g. Cook, Reservation, Customer etc.
- Event First Domain Driven Design places the focus on the activities or events that occur in the domain. For instance – Customer makes a reservation, Server places an order, Food is serve to the customer.
- Using Event First Domain Driven Design we start by defining the activiites, then group those activities to find logical system boundaries.
Domain Activities
There are some specific categories of activities. One of the types of activities that we deal with in domain-driven design is called a command.
Commands
Commands are a kind of activity that occurs in the domain. It represents a request to change the state of the domain. They can be rejected and are usually phrased as a request.
- The Commands represents a request to perform an action.
- The action which have not yet been happen can be rejected.
- It causes a change to the state of the domain.
- It usually deleiver to a specific destination.
- For instance, add an item to an order, pay a bill, prepare a meal etc.
Events
An event is an activity that occurs in the domain.
- Events represent an action that happened in the past.
- Events are often broadcast to many destinations.
- In a command message usuallly going to a specific recipient, but in an event message is send to anybody who cares.
- You will broadcast it to many different microservices or many different destinations.
Queries
- Queries represents a request for information about the domain.
- Because they are a query, thats why a response always come.
- Queries should not change or alter the state of the domain.
- Examples – Get the details of an order, Chech if a bill has been paid etc.
In a reactive system Commands, Events, and Queries are the messages. In addition, they form the APIs for Microservices.
Conclusion
In conclusion, a Microservice is a self-contained system that serves one specific purpose. We use Domain-Driven Design (DDD) mainly to define and design such a system.
Domain-driven design is all about bringing the software engineers and the business together to function as a development team.
References
http://domainlanguage.com/ddd/reference/
