Microservice architecture is not simple at all, especially when compared with a traditional monolithic solution. However, with proper architectural decisions we can tear down the big monster into simple problems that can be solved in a way in which they will no longer contribute to the overall complexity and let us focus on the business domain rather than technical aspects.

You may wonder, why is it important to “hide” the technical aspects of a software solution, when technology is cool and developers get excited about every new solution for well known problems? Well it might not be an issue at the very beginning of a project when adding new technology to the existing stack will raise the enthusiasm of the team while implementing less exciting functional requirements, and the team is growing in terms of technical skills.

But this “let’s try” attitude in the long run, usually leads to a couple of major problems which might not be evident at first but sooner or later will show their ugly face, especially when dealing with an already complex architectural style such as microservices.

Here are the most common issues I encountered:

• Extending the team can become very difficult due to an overloaded technology stack and tooling, often requiring highly skilled developers while the business domain is relatively simple. And we all know senior developers with a very specific skill set are not on every corner.
• The solution can become rigid towards changes or extension due to technical dependencies, or just because technology is mixed in many ways with the domain specifics, requiring all kinds of extensive refactoring even for simple change requests.
• Last, but not least, technology is cool, but what’s cool today, tomorrow (or in 2 to 5 years) is ‘legacy’ or ‘deprecated’ and can become a swear-word in the mentality of a team which continuously focuses on technical aspects rather than functional ones.

If you read this article until this point, you probably found yourself in one or more of the above situations and it’s a fair expectation from you, to get a solution or some kind of guidance.

So what is the solution to have a system with a complex business domain using microservices architecture with all of its benefits but without requiring the “crème de la crème” of developers with deep technical understanding?

Yes, the answer is Abstraction, at least in my opinion.

Abstraction is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics

Applying this in a domain centric architecture model, means that technical aspects have to be taken away, in order to put in the spotlight the characteristics essential for the business domain.

But if this doesn’t make much sense to you, instead of watching the entire Spiderman franchise looking for an explanation, let me invite you to follow me on the next couple of articles in which I’ll discuss the most common problems from an architectural perspective and demonstrate how abstraction is significantly reducing the impact of technology on the overall complexity.

I’ll show examples brought from an existing microservice based solution based on .net core using serverless azure functions as host, but they apply to any distributed system, regardless of the programming language or hosting platform.

So here are the topics I’d like to cover:

1. How to implement distributed processes
2. How to implement inter service communication 
3. How to implement caching
4. How to implement configuration management
5. How to implement logging
6. How to implement exception handling
7. How to improve the code quality of unit tests
8. How to handle concurrent processes using pessimistic concurrency
9. (Coming soon)To implement integration tests that are running in fraction of seconds