This content originally appeared on Level Up Coding - Medium and was authored by Giedrius Kristinaitis
Concepts and entities in a microservice architecture should be contextual.
What is context? Context is the setting of something, it’s a background that allows you to fully understand something.
Does everything have a context attached to it? In other words, are there things that are always absolute no matter how you look at them?
Apparently, when it comes to microservices, context is often non-existent and concepts become absolute. Ignoring context is one of the biggest mistakes you can make when designing a microservice architecture… or, really, when designing software in general.
Context Matters
Concepts are not absolute
Your services need to be independent and focused on one purpose only. That one thing is absolute when you look at only it and nothing else, if you introduce an interaction between that thing and something else, then you have a context of interaction. There can be different interactions for different purposes, which means that one service can be involved in multiple contexts, which means that even microservices are relative. Another win for Einstein and a loss for Newton.
Context matters a lot if you want to achieve independence. If you want to make a service, or a group of services, truly independent it must have the concepts it’s working with mean one thing to only the service/group, and nothing else. In no other service, or a group of services, does the same concept have the same meaning. That doesn’t mean that literally every service must define concepts differently.
Bounded context
What I’m talking about has a name. The folks of our industry call it the bounded context. It’s a context in which a given concept applies. The term comes from domain-driven design (DDD).
For example, let’s say work with videos. Let’s say you’re doing microservices. What does the concept of a video mean in your microservice architecture? If the answer isn’t “it depends on the context” then something’s seriously wrong with the architecture. Simply put, if you’re passing around entities everywhere in the same form and always with the same data, then you’re going in the wrong direction.
A video could mean different things depending on the context.
In the context of data storage, a video is a file with its size information attached to it.
In the context of access management, a video is a file with access rules attached to it.
In the context of sales, a video is a product with price information attached to it.
These are examples of different bounded contexts and different entity meanings depending on the context. The services that work with a given context should also work with the meanings that only apply in that context.
What Happens When You Ignore Context
When you ignore context you end up with god entities or god concepts that no matter the context always have all the information about them, and that information is often completely useless in some contexts.
Let’s come back to the video example. If you ignore context, then you have a god entity with everything attached to it: file, size, access rules, marketing information, and price.
The chain reaction
When you have god entities it’s very easy to lose track of the sources some information comes from.
When you lose track of the source of information you start misusing it everywhere and use it where it can’t be accessed without a god entity or where it should be accessed in a better way.
When you lose track of sources of information and start misusing it you lose the ability to change how information is represented, because there are a lot of places that depend on the way it is.
When you lose the ability to change the shape of information you start adding more information to god entities.
Eventually, everything becomes entangled and if there were any different contexts at all the boundaries between them fade away, and you’re left with a distributed monolith.
Ignoring context sets off a pretty serious chain reaction, and then the only thing that’s bound (pun intended) to happen is failure.
What’s even worse, the chain reaction is self-sustaining. As you start adding more information to god entities, losing track of sources of information is even easier, misuse is even easier, growing god entities even more becomes even easier, and the reaction spirals out of control.
Information Conversion
If you don’t want the chain reaction to take place you should respect context.
Translating information as it passes from one bounded context to another is the way to go. I know, it looks like pointless extra work and could seem like overkill, but it’s not.
Whenever information crosses a boundary between contexts, it should be converted by an adapter (or translator, or transformer, whatever you want to call it) into whatever format is required by a specific bounded context.
That doesn’t mean that every single service within the architecture should be doing conversions. Remember, a bounded context can consist of more than one service. The important thing is to convert information when its meaning changes.
So, when a video stops being a product with marketing information and becomes a file with access rules, you should translate the information and work with a form that’s meaningful in a given context.
What can mean the same thing in different contexts is the unique identifier. After all, you need to have it to know what is what when crossing from one bounded context to another.
Ignoring context is something you should avoid when designing microservices.
Unfortunately, people often don’t try to avoid it, because translating information requires some work to be done, and, as we all know, nobody likes doing work they don’t understand the benefits of.
The same principles can be applied not only to microservices, but to software design in general. Not only can, I think they should be applied.
I’ll talk more about the problems that god entities create in later parts of this mini-series.
Thank you for reading!
Microservice Design Mistakes (Part 1): Ignoring Context was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Giedrius Kristinaitis
Giedrius Kristinaitis | Sciencx (2022-10-30T13:19:32+00:00) Microservice Design Mistakes (Part 1): Ignoring Context. Retrieved from https://www.scien.cx/2022/10/30/microservice-design-mistakes-part-1-ignoring-context/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.