A service boundary groups a service’s interface logic, business logic, and required data schemas so its components can be isolated, independently versioned, and deployed. Leaving schemas in a shared data store weakens that isolation. section 16.5
When defining boundaries during modernization:
- Identify business service boundaries by focusing on logic first and data second; using legacy data boundaries to split services can lead to repeated migration work. section 16.5
- Avoid extracting and reusing existing code by default; a complex, poorly understood algorithm can be an exception. section 16.5
Clean service boundaries limit deployment and testing scope, support independent scaling, and make continuous deployment easier. Containerized services can be redeployed with a Kubernetes rolling update. section 16.2.1
