DDD.7 – Using the language

This chapter is a long example of how  project architecture may evolve.

There aren’t many new concepts approached, nevertheless, in the end of the chapter there are three interesting design patterns mentioned:

• Anti-corruption layer
• Enterprise segments
• Strategy

Anti-corruption layer

An anti-corruption layer is an abstraction that works like a filter/translator/mapper between two systems.
For example, lets suppose we have two micro services that need to communicate. Service A sends data to request an action from service B and receives some data back. However, these services were not initially designed to communicate with each other, so their data structures and naming don’t match. Thus, we need to create a structure to sit between both services and make the translation and filtering of data.
This middle-ware structure will receive data from service A, map it into a structure that service B can understand, in the process also filtering out the unnecessary data provided by A, and send the data to B. It then receives a data structure back from B and translates it into a structure that A can understand, again also filtering out any unnecessary data.
This helps prevent that changes to the data provided by one of the services will corrupt the other one, or at least there will be a clear location where the data mapping can be rearranged;

Enterprise segments

Sometimes we have a few different entities, with their internal data and their associated logic, and we have a process that deals with a few instances of those different entities. Maybe there’s even some coordination needed between those entities, although not necessarily.
The key factor is that the process only needs a few properties of each of those entities, and it would be really handy and clean to just treat those few properties as if they were in one same entity.
An enterprise segment is used for this purpose. It is a wrapper around properties of a few different entities and it will allow client code to use these independent entities as if they were one. As far as the client code can see, it is in fact one concrete entity. We can see it as a virtual entity that wraps around data that belongs to concrete entities, in order to represent another business concept.

Strategy

Lets suppose we want to model the process of transporting something from one location to another. If we just want to transport a person, a taxi will suffice and a route will be chosen. However, if we want to transport furniture, we will need a truck and possibly we need to use another route.
The process to execute is still the same, but the strategy used is different, depending on the context!
To implement such a design pattern, we will have a main class who will represent the process. This main class will contain a set of classes who will implement different strategies of executing the same process.
When the client code calls for the execution of the process, it will also provide the context, with which the main process class will decide what specific strategy to use.

This post is part of a set of posts with my personal notes about all the chapters in the book “Domain Driven Design” by Eric Evans. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.