Finding service boundaries

Microservices · lesson 2 of 33 · 4 min read

Draw boundaries around business capabilities so services stay independent instead of chatty.

Open this lesson in the learning hub

Key points

  • Split by business capability, not by technical layer. "Orders" is a service. "The DAO tier" is not.
  • A bounded context is where one word means one thing. "Customer" in Billing is not "Customer" in Support, and that seam is a boundary.
  • Each service owns its database. No other service reads those tables. Sharing a schema recreates the monolith and adds latency.
  • Boundary test: if a routine feature needs coordinated changes in three services, the boundary is in the wrong place.
  • Copying a little data between services is normal. Copying the rules that change that data is not.

Good boundaries follow the business, and every service keeps its own data private.

Monolith vs microservices Synchronous calls done right

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Microservices course, and every lesson in it is listed on the Microservices contents page.