Finding service boundaries
Use domain-driven design - business capabilities, bounded contexts, ubiquitous language and aggregates - to draw boundaries that last.
- Decompose a system by business capability rather than by technical layer
- Identify bounded contexts and the ubiquitous language inside each
- Recognize good boundaries: high cohesion inside, low coupling between
The hardest part of microservices isn’t the technology - it’s where to draw the lines. Draw them wrong and every feature needs changes in four services. The most reliable guide is the business itself.
Decompose by business capability, not by technical layer. A “database service”, a “UI service” and a “logic service” mean every feature touches all three. Instead, Galactic Noodle Express has capabilities: Menu, Ordering, Payments, Kitchen, Delivery, Notifications. Each changes for its own reasons and could have its own team.
Bounded contexts and ubiquitous language
Domain-driven design (DDD), from Eric Evans’ 2003 book, gives the vocabulary:
- A bounded context is a boundary within which a model and its words have one precise meaning. It’s the natural candidate for a service.
- The ubiquitous language is the shared vocabulary developers and domain experts use inside a context - in conversations and in the code.
- The same word often means different things in different contexts - and that’s fine. That’s exactly where a boundary belongs.
At Galactic Noodle Express, an “order” in Ordering is a customer’s purchase with a price and an address. In the Kitchen it’s a ticket: dishes to cook, in what order, at which station. In Delivery it’s a parcel with a weight and a destination planet. One giant Order class trying to be all three is how monoliths become mud.
Try it
Which context owns it?
Sort each concept into the bounded context it belongs to.
“Dish names, descriptions and prices”
“A customer’s cart and checkout”
“Refunding a charge”
“Which cook station prepares the broth”
“Rocket route and estimated arrival time”
“A ticket of dishes to cook, with timing”
“Fraud checks on a card”
Aggregates, cohesion and coupling
Inside a context, an aggregate is a cluster of objects changed together as one unit with one consistency rule - an Order with its line items, say. Transactions stay inside one aggregate; between aggregates (and services), you accept eventual consistency.
Good boundaries have high cohesion (things that change together live together) and low coupling (services rarely need each other to get work done). Two practical signals:
- Chatty calls: if service A calls B fifty times per request, they probably belong together.
- Co-change: if two modules nearly always change in the same pull request, splitting them guarantees coordinated releases.
1owner = {"cart": "orders", "checkout": "orders", "pricing": "menu", "dishes": "menu", "charge": "payments"}
2calls = [("checkout", "cart"), ("checkout", "pricing"), ("checkout", "pricing"), ("checkout", "charge"),
3 ("cart", "pricing"), ("cart", "pricing"), ("dishes", "pricing")]
4
5internal = sum(1 for caller, callee in calls if owner[caller] == owner[callee])
6cross = [(owner[caller], owner[callee]) for caller, callee in calls if owner[caller] != owner[callee]]
7print(f"internal calls: {internal}, cross-service calls: {len(cross)}")
8for pair in sorted(set(cross)):
9 print(f" {pair[0]} -> {pair[1]}: {cross.count(pair)}")internal calls: 2, cross-service calls: 5 orders -> menu: 4 orders -> payments: 1
Ordering calls Menu’s pricing four times: a hint that pricing might belong with Ordering - or that Ordering should keep its own copy of prices (an idea the next lesson develops).
Key takeaways
Decompose by business capability, not technical layer.
A bounded context gives each word one meaning; it’s the natural unit for a service.
The same term meaning different things in different contexts marks a boundary.
Aim for high cohesion inside services and low coupling between them; chatty calls and co-change are warning signs.
Lesson quiz
7 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: simulate microservice patterns in Python
Build small Python simulations of the patterns - routers, sagas, outboxes, circuit breakers, traces - and run them against sample inputs. They run locally in your browser; no servers or containers needed.
Measure the coupling
The input has module -> service lines, ---, then call lines caller callee count (how many times per order). Print the internal and cross-service call totals, each cross-service pair with its total sorted by count (highest first, ties alphabetically), and a coupling ratio coupling: 38% (cross / all, rounded). Finally print consider merging: a + b for any pair of services whose calls in either direction add up to more than half of all calls, or consider merging: none.
- Chatty pricing
- Healthy
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Spot the overloaded words
Each input line is a glossary entry: Context | term | meaning. Print every term that has different meanings in different contexts (ignoring case for the term), alphabetically, with each context’s meaning in input order - Order: Ordering = a customer’s purchase; Kitchen = a ticket of dishes to cook - then boundary hints: N terms. Terms with only one meaning aren’t listed.
- Noodle glossary
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…