• Skip to main content
  • Skip to primary sidebar
BMA

BeMyAficionado

Inspire Affection

Principles Of Microservices: How To Architect A Solution

December 31, 2019 by varunshrivastava Leave a Comment

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

  • Why Would You Use Microservices (Advantages and Disadvantages)?

The very first principles help you to model your services.

Table of Contents

  • Principle 1 – Model Around Business Domain
    • To Add/Subtract Anything, it requires a change in all the three layers
    • Developers Mindset Was Geared Towards the Same Tech
    • Contracts Between Layers Were Assumed to be Valid and Truthful
    • Did Not Bother About Chattiness
    • Segregation Of Team Across Different Layers
    • Not Easy To Explain In Layman Terms
    • How Does Modelling Around Business Domain Help

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:

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 write new articles. So if you are interested then make sure to subscribe. I will keep you updated.

Related

Filed Under: Blogging, Programming, Technology Tagged With: microservices, principles of microservices

Primary Sidebar

Subscribe to Blog via Email

Do you enjoy the content? Feel free to leave your email with me to receive new content straight to your inbox. I'm an engineer, you can trust me :)

Join 874 other subscribers

Latest Podcasts

Recent Posts

  • Is The Cosmos a Vast Computation?
  • Building Semantic Search for E-commerce Using Product Embeddings and OpenSearch
  • Leader Election with ZooKeeper: Simplifying Distributed Systems Management
  • AWS Serverless Event Driven Data Ingestion from Multiple and Diverse Sources
  • A Step-by-Step Guide to Deploy a Static Website with CloudFront and S3 Using CDK Behind A Custom Domain

Recent Comments

  • Varun Shrivastava on Deploy Lambda Function and API Gateway With Terraform
  • Vaibhav Shrivastava on Deploy Lambda Function and API Gateway With Terraform
  • Varun Shrivastava on Should Girls Wear Short Clothes?
  • D on Should Girls Wear Short Clothes?
  • disqus_X5PikVsRAg on Basic Calculator Leetcode Problem Using Object-Oriented Programming In Java

Categories

  • Blogging
  • Cooking
  • Fashion
  • Finance & Money
  • Programming
  • Reviews
  • Software Quality Assurance
  • Technology
  • Travelling
  • Tutorials
  • Web Hosting
  • Wordpress N SEO

Archives

  • November 2024
  • September 2024
  • July 2024
  • April 2024
  • February 2024
  • November 2023
  • June 2023
  • May 2023
  • April 2023
  • August 2022
  • May 2022
  • April 2022
  • February 2022
  • January 2022
  • November 2021
  • September 2021
  • August 2021
  • June 2021
  • May 2021
  • April 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • February 2020
  • December 2019
  • November 2019
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • January 2019
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016

Tags

Affordable Hosting (4) algorithms (4) amazon (3) aoc-2020 (7) believe in yourself (4) best (4) database (4) earn money blogging (5) education (4) elementary sorting algorithms (4) experience (3) fashion (4) finance (6) Financial Freedom (7) food (7) friends (3) goals (5) google (5) india (10) indian cuisine (5) indian education system (4) java (16) life (16) life changing (4) love (4) make money (3) microservices (9) motivation (4) oops (4) podcast (6) poor education system (4) principles of microservices (5) problem-solving (7) programmer (5) programming (28) python (5) reality (3) seo (6) spring (3) success (10) success factor (4) technology (4) top 5 (7) typescript (3) wordpress (7)

Copyright © 2025 · Be My Aficionado · WordPress · Log in

Go to mobile version