Firstly Eric began explaining how microservices talk to each other by using Context Maps. He described a microservice as a part of the system run by an autonomous team, with boundaries between each one. Messages are sent between the services in the language of each context. Eric then went on to explain all the different ways the language could be sent between each of the microservices.
A microservice that consumes a message from another can conform and continue to use the language of that bounded context it is consuming, or it can decide to use an anti corruption layer to translate the language, partner by exchanging messages in each language, or they can both decide to use an interchange context (think of this like a German and a Frenchman having a meeting in English).
Eric explained the problem you can face if both microservices use the same language, but for different contexts. This is where you end up with a Big Ball of Mud. For example the meaning of an account can be different between the sales team, the software team and the finance team in a company. You can get very confused using the same language when it means different things in different contexts. When this happens you are no longer conforming when you consume the messages, as you are modifying the language.
Big Ball of Mud i.e. confused language is contagious. Especially when other parts of the system consuming your messages and conforming to your language.
Anti corruption layers can help address this problem and protect you from the outside world, but this isn’t a good reason to choose the pattern. By defending against the outside world you’re masking a bigger problem.
This is where the Interchange context comes in. If you want to refer to the DDD book, go check out the section on PUBLISHED LANGUAGE.
Of course this is my very brief overview of the talk. There is so much more content and nuance I haven’t covered.
Biggest takeaway for me was to start documenting our DDD microservices system using Context Maps. Currently I think a lot of this is in my head and assumed that the rest of the team know/understand. Which segwayed nicely into the next talk on Documentation.
Question: Does the size of a company have an impact on the size of the microservice team / context boundary? How do big teams and small teams differ? Would love to hear how others have broken their teams up.