How to granulize domain services?

When someone asks your team to granulise your domain services into microservices, don’t your team have different opinions, and making decisions becomes more difficult?

Don’t you yourself feel confused? Should this be a single service or should we break it into two or more microservices?

How to solve this dilemma?

According to me, we can consider the below drivers to decide on this

Service scope

Service scope is the most common thing that we usually consider while breaking a service into smaller ones.

Considering the domain of social networking, here we have multiple scopes like customers, media, notifications, and many more.

As per scope, we can create different services for all of these.

But do you think that’s enough?

Size of component

Don’t you think the size of the component also matters?

Can you make a single service for customers? Would that be enough?

Will a single service be able to manage customers’ likes, comments, preferences, profiles, etc?

Don’t you think this service is doing a lot?

A solution to this is, can break it into multiple services.

But can we divide every large component into smaller ones without understanding their cohesion?

Cohesion

The degree and manner to which the operations of a particular service interrelate.

Notification service has multiple ways to send the notification email, message, postal service, and push notification. Can we divide this also into multiple services?

In my opinion, NO.

Why?

Because they have relatively strong cohesion — all of these relate to notifying the customer. We as a developer are so tempted to divide services into smaller components without considering the purpose behind them.

Scalability

Scalability is another important driver to consider while separating services. For example

Consider media service which has two components image and video. With the increasing demand for 2-minute videos, the scale of it is increasing at a higher speed.

If we don’t separate then the image functionality must be unnecessarily scaled to meet video demand, impacting cost and many other factors. Breaking this would allow scaling both of them independently to meet their demand.

Code volatility

The rate at which source code changes

Code volatility is also an important factor to consider. Let’s consider the notification service component postal which is a rarely used functionality, its rate of change is minimal. Now any change in another frequently used service will force us to test postal functionality also and its deployment risk also increases.

Here dividing the components into two components will be a smart move. This will in turn reduce testing and deployment risk and other functionalities are not disrupted.

These are a few drivers which can help us to granularise services and I would love to share a few more with you. I will share it soon in my next post.

You can follow and subscribe to stay updated. :)

Reference:

Software Architecture: The Hard Parts

by Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani