Microservice granularity: Per domain model or not?

Question

When building a microservice oriented application, i wonder what could be the appropriate microservice granularity.

Let's image an application consisting of:

• A set of various resources types where each resource map a given business model. (ex: In a todo app resources could be User, TodoList and TodoItem...)

• Each of those resources are saved within a NoSQL database that could be replicated.

• Each of those resources are exposed through a REST Api

• The application manage an internal chat room.

• An Api gateway for gathering chat room and REST api interaction.

• The application front end: an SPA application connected to the API Gateway

---

The first (and naive) approach when thinking about how microservices could match the need of this application would be:

1. One monolith service for managing EVERY resources and business logic: By managing i mean providing the REST API for all of those resources and handling the persistance of those resources within the database.
2. One service for each Database replica.
3. One service providing the internal chat room using websocket or whatever.
4. One service for Authentification.
5. One service for the api gateway.
6. One service serving the static assets for the SPA front end.

---

An other approach could be to split service 1 into as many service as business models exist in the system. (let's call those services resource services)

I wonder what are the benefit of this second approach. In fact i see a lot of downsides with this approach:

• Need to setup an inter service communication process.
• When requesting a service representing resource X that have a relation with resource Y, a lot more work are needed (i.e: interservice request)
• More devops work.
• More difficulty to share common code between resource services.
• Where to put business logic ?

---

When starting a fresh project this second approach seams to me a bit of an over engineered work.

I feel like starting with the first approach and THEN split the monolith resource service into several specific services depending on the observed needs will minimize the complexity and risks.

What's your opinions regarding that ? Is there any best practices ?

Thanks a lot !

Answer 1

It is the key problem of the microservices or any other SOA approach. It is where the theory meets the reality. In general you should not force the microservices architecture for the sake of it. This should rather naturally come from functional decomposition (top-down) and operational, technological, dev-ops needs (bottom-up). First approach is closer to what you would need to do, however at the first step do not focus so much on the technology aspect. Ask yourself why would you need to implement a separate service for particular business function. Treat it as a micro-application with all its technical resources. Ask yourself if there is reason to implement particular function as a full-stack app.

• Some, of the functionalities you have mentioned in scenario 1) are naturally ok, such as 'authentication' service - this is probably good candidate.
• For the business functions decomposition into separate service, focus on the 'dependencies' problem, if there are too many dependencies and you see that you have to implement bigger chunk of data mode - naturally this is not a micro service any more.
• Try to put litmus test , if you can 'turn off' particular functionality and the system still makes sense - it is the candidate for service or further decomposition

Answer 2

The first approach is not microservice way, by definition.

And yes, idea is to split - each service for Bounded Context - One for Users, one for Inventory, Todo things etc etc.

The idea of microservices, at very simple, assumes:

1. You want to pay extra dev-ops work for modularity, and complete/as much as possible removal of dependencies between different bounded contexts (see dev/product/pjm teams).
2. It's idea lies around ownership, modularity, allowing separate teams develop their own piece of code, without requirement from them to know the rest of the system . As long as there is Umbiqutious Language (common set of conventions/communication protocols/terminology/documentation) they can work in completeley isolated, autotonmous fashion.
3. Maintaining, managing, testing, and develpoing become much faster - in cost of initial dev-ops and sophisticated architecture engeneering investment.
4. Sharing code should be minimal, and if required, could be done to represent the Umbiqutious Language (common communication interface/set of conventions). Sharing well-documented code, which acts as integration/infrastructure mini-framework, and have special dev/dev-ops/team attached to it ccould be easy business, as long as it, as i said, well-documented, and threated as separate architecture-related sub-project.

Properly engeneered Microservice architecture could lessen maintenance and development times by huge margin, but it requires quite serious reason to use it (there lot of reasons, and lots of articles on that, I wont start it here) and quite serious engeneering investment at start.

It brings modularity, concept of ownership, de-coupling of different contexts of your app.

My personal advise check if you really need MS architecture. If you can not invest engenerring though and dev-ops effort at start and do not have proper reasons for such system - why bother?

If you do need MS, i would really advise against the first method. You will develop wrong thing's, will miss the true challenges of MS, and could end with huge refactor, which could take more work than engeneering MS system from start properly. It's like to make square to make it fit into round bucket later.

Now answering your question title: granularity. (your question body bit different from your post title).

Attach it to Domain Model / Bounded Context. You can make meaty services at start, in order to avoid complex distributed transactions.

First just answer question if you need them in your design/architecture? If not, probably you did a good design. Passing reference ids between models from different microservices should suffice, and if not, try to rethink if more of complex transactions could be avoided.

If your system have unavoidable amount of distributed trasnactions, perhaps look towards using/making some CQRS mini-framework as your "shared code infrastructure component" / communication protocol.