Domain driven design is a design standard to develop complex software in a modular,
scalable and loosely coupled way, following the best practices in terms of separation of concerns,
and it was created by Eric Evans and presented in his 2003 book,
"Tackling Complexity in the Heart of Software" .
Very quickly a domain model is the richest, possible comprehension of processes, policies
and rules inside the domain and is described by an ubiquitous language which is created by the
domain experts and the developers in order to translate and normalize and model vision
of the domain. It's also the very first step in order to conceive
a canonical perspective of this specific core domain. Depending on the problem we are trying
to solve or the system complexity we might need to address other related domains which will be called
bounded contexts. Each bounded context will probably need to have its own ubiquitous
language which it means that we can end up with several different canonical models.
Context maps is basically the relationship between different bond contexts and the very
existence of a bonded context anticipates the need to have a process of continuous integration
between, in this case, the core domain and bounded context, to guarantee model integrity,
which will help keeping the model properly unified.
There are many different communication partnerships between bounded contexts,
for instance the customer supplier went to teams where, one plays the customer role in the core
domain side, downstream as the client, and another player, another place, the supplier role, the
domain feeds the client, however the client has some capacity to
influence and negotiate through proper acceptance testing, interface negotiation and by keeping a
tight continuous integration process. The Shared Kernel is another approach
where two teams agree to share the responsibility to manage a shared context.
These shared contexts might contain a specific subset of the model, code or data. Any change
must be synchronized between the teams in some way and this can be kind of challenging to manage
but very often this approach tends to reduce duplicated libraries and superfluous code.
The conformist model is another approach of the customer supplier.
It's a kind of customer supply relationship, where the customer has limited
or no capacity at all, to influence or negotiate.
In this case, the best path is to try to be confirmed with the supplier, upstream model,
and hope for the best, as the customer completely depends on the supplier, for good intentions.
Then and finally, the anti-corruption layer, in this case, if the downstream customer
doesn't completely trust the upstream supplier, a solution might be to introduce an intermediary
anti-corruption layer. In this case because the cost or risk to get the core domain
model break is too high to assume. Okay, this is achievable through translation and proper mapping.
Then implementation patterns, to implement the different communication partnerships, we
need implementation patterns, and simplistically, we can apply three different implementation
patterns RPC, where the core domain will basically rely on the service registry to find the service,
which will provide them some data from the bounded context. The service registry keeps information
on where to call the bounded context service and how to call it, as well through a proper contract,
such as weasel for instance if which will describe the service if we are talking about SOAP.
The second implementation pattern is messaging, and in this case, an event can be,
is all about events, and an event can be defined as a fact that occurs inside our core domain
representing a significant changing state which in this case is relevant to the bounded context.
Third and final implementation pattern, is Rest, and in this case, typically,
this describes utilization of HTTP, to obtain data by executing
CRUD operations in formats based on XML or JSON.
So, wrapping up, we have been talking about Domain Driven Design,
with an objective in mind, which is to understand its importance when
discussing distributed architectures and microservices, in particular.
A microservices architecture consists in composing systems with bounded, isolated components. Each
microservice should constitute a proper business capability. Business capabilities though exposed
through an API layer, will internally translate the consumption of a self-contained
and a centralized service with its own data source or database. Any relevant state changes,
could imply triggering the main events from the bounded context to another bounded context.
I hope it got clear now, to you, that domain driven design principles respond to the
most basic needs of complex distributed architectures, including microservices.
How to implement this, is something we are going to find out on the next episode of this series.
Thank you very much.