How do you define service boundaries when decomposing a monolith into microservices?

The boundaries of services when decomposing a monolith into microservices are determined based on business domains and contexts (bounded contexts) in terms of Domain-Driven Design (DDD). The main principles:

• Isolation of business functions: each service is responsible for a specific business process or entity.
• Minimization of dependencies: services should be as independent as possible so that changes in one do not affect others.
• Single responsibility: a service should have a clearly defined scope of responsibility.
• Data ownership: a service owns its database and does not share it directly with others.

Practically, this is achieved through analyzing the current monolith, identifying modules with high internal cohesion and low external cohesion, as well as discussing with business experts to identify natural boundaries.

Example: if the monolith has modules "Users", "Orders", and "Payments", it makes sense to allocate three microservices with clear APIs and their own databases.