Principles Of Microservices: How To Architect A Solution


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 implementator 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.

#1. Modelling 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

Not only because it requires a change in all the three layers but also because oftentimes these three layers are maintained by three different teams. And this prevents rolling out quick changes.

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

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.

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:

Microservices

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 update the same as I write about other principles. 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 web developer. He is a passionate blogger and loves to write about philosophy, programming, tech and relationships. He works as a Software Developer. This is his den, you can get in touch with him here anytime you want.
  • Website Search
  • Free Ebook Download ($7.06 Value)



  • Grab the Deal Now!

    Hostgator  Starting @$3.95/mo

  • DigitalOcean Free Credits!