How to determine the boundaries of a microservice?

The boundaries of a microservice are determined by which business function it performs fully and independently. The main guideline is business logic, not technical structure.

#1. Focus on the domain

This uses the bounded context principle from DDD: one service equals one clear part of the business. Example: "Users", "Orders", "Payments", "Delivery". Each service is responsible only for its own context and does not intrude on another's.

#2. Look for natural dependencies

If two modules often change together, they most likely should be in the same service. If they live independently and rarely interact, it is worth splitting them.

#3. Look at data and its ownership

Each service should own its own data and not access other services' databases directly. The boundary often falls where the "owner" of the data changes.

#4. Minimize cross-service calls

If two services exchange too many requests, the boundary was probably chosen poorly. A good service is one that does most of the work itself.

#5. Make the service complete in meaning

It should be able to perform a business function from start to finish, without direct dependency on others. Example: the "Payments" service should verify payment itself rather than asking "Orders" for permission.

Summary:

The boundary of a microservice lies where its business responsibility ends. It should be autonomous, own its data, and perform a complete task without tight coupling to others.