Principles Of Microservices: How To Architect A Solution7 min read

Every enterprise has its own principles.

Principles that takes it towards the goals.

Principles that give birth to practices which are the underlying foundation for all the implementation.

Similarly, Microservices has its own set of principles that helps its implementer to make the correct decision when given multiple options to choose from.

Principles are like guiding markers. It helps to make a better decision, helps to choose better that will take the enterprise closer to its goals.

In this article, I will talk about the Principles Of Microservices. The guidelines which you would want to stick too at all times while designing a microservices architecture for your enterprise.

By any chance, if you have not read my previous article on Microservices then please do. It contains some useful information

The very first principles help you to model your services.

Principle 1 – Model Around Business Domain

The microservices must always be designed around the Business Domain.

Let me explain it to you by talking a little bit about the traditional architecture that enterprises have been following so far.

Traditionally, the enterprises use to follow the 3-tier architecture. This 3-tier architecture consists of a:

  • Presentation Layer
  • Business Logic Layer
  • Data Access Layer
Traditional 3-Tier Architecture
Traditional 3-Tier Architecture

This was a very simple architecture to understand. No doubt about it.

All the presentation logic resided at the presentation layer, all the code that deals with Business Logic of the application resides in the middle layer and the data access part resides in the last layer.

And the flow is unidirectional. The flow always goes from Presentation to Data Access and not vice versa.

It was easier to explain this architecture to someone new joining the enterprise with no industry experience at all. And this helped people to get started quickly. But there were multiple downsides to it.

To Add/Subtract Anything, it requires a change in all the three layers

This is a major drawback.

A single feature addition, as simple as adding a new property to your frontend requires the change in all the three layers.

Requires a change in all three layers
Requires a change in all three layers

If we go further back in time when organizations did traditional monoliths, it was usually one team that has to work on all the three layers.

one team - 3 different codebases
One Team – 3 Different Codebases

And by three layers I mean 3 different codebases.

One Team – 3 Codebases <- this sounds daunting but it actually worked well at that time.

But not for long.

As the enterprise grew, business ask grew, which intern increased pressure on the developers to develop features faster and reduce the time to market.

Now, this model was preventing the growth of the enterprise and putting pressure on developers.

Apart from this, there were other problems as well.

Developers Mindset Was Geared Towards the Same Tech

Obsessed with one and only one technology
Obsessed with one and only one technology

As one team dedicatedly work on one codebase, their knowledge and mind were all geared towards that same technology stack.

One may argue that this is better for the developer as he will become the expert of that field. But if you ask me (developer), I would not want to work on the same project for long. It isolates me from all the wonders happening around me.

Knowledge ~ Exploration

Contracts Between Layers Were Assumed to be Valid and Truthful

Avoids Incoming Validation is added in monoliths
Smart Move

As there was only one person/team working on all the three codebases, there was no need for contract testing. Every incoming request was assumed to be valid and truthful.

They didn’t give much attention to validation of the incoming data (data coming from other layers) because they are the ones who have coded it. And they are sure what is incoming. So they never felt a need for validation.

Did Not Bother About Chattiness

Since one developer or one team was working on all the different codebases – they didn’t bother about the network payload, performance, load and boundary restrictions.

Thus there was a need for a new model.

And a new model took its place.

Segregation Of Team Across Different Layers

In this new model, each layer was developed by individual teams.

Three layers are managed by three different teams
Three layers are managed by three different teams

This new model did take the load off the developer and solve some of the earlier problems but as you know – It is always a tradeoff that we make. So, this new model also brought its own share of problems.

Now the problem is this – for a single change, it required coordination between all the three teams. And this prevented rolling out quick changes.

I have kept these diagrams small and simple for the sake of explanation. These layers can go deeper, multiple layers inside each layer and it makes a single change very difficult.

To get rid of this silos, enterprises started looking for a better and more independent architecture.

Not Easy To Explain In Layman Terms

3-tier architecture seems simple enough to explain to a technical person. But it is not straightforward to explain it to a non-tech person.

You see, Business people talk in terms of features and use Business terms. They would not understand a word if you would talk in this technical term and there will be a communication hole in between.

On top of that, a single feature requires 3 different teams to work in collaboration. So there is an overhead of managing the three teams as well.

Both of these drawbacks can be taken care when you model your services around Domain and not around technical layers.

How Does Modelling Around Business Domain Help

The major advantage that you get with Modelling around Business Domain is that it gets easy to explain to others.

For example, take a look at the below image:


This image is fairly easy to demonstrate and understand. Clearly, it shows that each microservice deals with an individual business domain. And how it interacts with each other.

Any non-tech guy will be able to better understand it without much explanation.

Furthermore, each service is owned by one team in its entirety so it is easier to roll out new changes. The intercommunication between the teams is good and fast.

What microservices has done here is that instead of making a horizontal slice, they have made a vertical slice where they are covering each part of every layer. Therefore, these models also fit well with the Agile software development model.

These two are major advantages of designing your microservices around business domains.

And it is the first principles of Microservices.

As the list is exhaustive and huge so instead of waiting for the entire article to complete I plan to write new articles. So if you are interested then make sure to subscribe. I will keep you updated.

  • Article By: Varun Shrivastava

  • Varun Shrivastava is an innovative Full Stack Developer at ThoughtWorks with around 4 years of experience in building enterprise software systems in finance and retail domain. Experienced in design, development, and deployment of scalable software. He is a passionate blogger and loves to write about philosophy, programming, tech and relationships. This is his space, you can get in touch with him here anytime you want.