1. Single Responsibility. Consumers of a service need to clearly understand its purpose.
2. High Cohesion and Exhaustiveness. All related functionality has to end up in the same service.
3. Low Coupling. Services should minimize dependencies on others — even if that means duplicating supporting code. Big codebases for microservices are OK as long as the services are cohesive and centered around a single business capability.

Imaging we have a patient data management system for hospital intensive care units (ICUs), built as a monolith. It manages patient information, prescriptions, treatment history, vital parameters, and provides a dashboard with current state and therapy.

❌ Wrong decomposition:

• dashboard
• care plan
• monitoring

Why? Consider we add a new drug into the system. All services must change:

• care plan — to prescribe it
• monitoring — to display past treatments with the new drug
• dashboard — to show current therapy

✅ Better approach:

• drugs
• vital parameters
• timeline (treatment plans, current state, history)

Why? Available drugs and vital parameters change in one place, while evolution of timeline does not affect other services. Each service owns a stable business concept, not a UI page.

Good microservice boundaries reduce change coordination, not just code size.