It was agreed that Ubiquitous Language must be consistently practiced within SHELF. Frank and Katie began to pay close attention to Peter’s vocabulary and corrected him when necessary. DDD started to settle in. But (there’s always a “but”) this was only the beginning. All those models built using the Ubiquitous Language, like everything else, need a place to live.
Divide and Conquer
There’s rarely one big shared universe where all models coexist peacefully. More often, it’s a chaotic mix of Core, Supporting, and Generic Subdomains. Managing that mess is nearly impossible.
To make matters worse, the same term can have different meanings in different Domains. For example: a “book” may be a product for sale in the Store Context. But the same word can also refer to demo copies sent by editors, which fall under the Acceptance Context. These demo books can’t be sold and must be returned. Same term, different meanings, different rules.
This is where the Bounded Context (BC) shines. It defines a boundary where the Ubiquitous Language remains consistent. That’s why it’s called Bounded. It provides a clear, safe space for models shaped by a shared language. A Bounded Context should be:
- deployable independently (for microservices)
- free of direct dependencies on other Contexts (both in microservices and monoliths)
As your system grows and a monolith starts becoming a bottleneck, a Bounded Context is the ideal candidate to be extracted into a microservice. If the architecture is clean, the transition should be smooth. It’s wise to use code quality tools to detect “leaks” between Contexts early and avoid technical debt.
Blueprints
Let’s visualize the Bounded Contexts in SHELF. There’s a Stationery Store where Buyers pay cash or use cards. There’s also an Online Store with digital payments. Books in both stores must first be available in Storage. Storage, in turn, depends on Acceptance, where Frank handles incoming demo books, reviews, and shipping.
Buyers can also post Reviews, but only for books that are actually in the system. When you think about it, it’s more complex than it first appears. Below is a diagram showing Bounded Contexts for SHELF’s Core Domain: selling books.
The most critical Context is Acceptance. If a cookbook isn’t accepted by Frank, it won’t enter Storage. If it’s not in Storage, it can’t be sold. And without something to review, no Review can be posted. Everything begins with Acceptance.
How Contexts Come Together
In reality, Bounded Contexts are not completely autonomous. Vocabulary and responsibilities may overlap, causing confusion. Don’t let that stop you, take time to study your Domains and Subdomains. You’ll likely notice that most BCs relate to one another in one of two ways: Upstream or Downstream.
Think of a river. It has a source (Upstream) and a mouth (Downstream). Water flows from the higher source to the lower mouth. If you block the river near the mouth, the source remains unaffected. But if the source dries up, the entire river disappears. The same principle applies to BC relationships. Here’s an updated diagram with stream-wise relationships:
You can now see how each Bounded Context depends on the others. For instance, Storage depends on Acceptance but is also required by both Stores. Remove Acceptance, and the rest collapse. Remove the Online Store, and the business still runs.
Pros and Cons
Let’s focus on Acceptance and Storage. Two dev teams are assigned: Team A handles the Upstream (Acceptance), Team B the Downstream (Storage). Which team has the advantage?
Team A (Upstream) enjoys independence. They can move fast without worrying much about others. But there’s a risk: poor decisions in Acceptance will ripple down and hurt Storage. Eventually, Downstream may push back and impose constraints on Upstream. That’s not ideal.
Team B (Downstream) has a harder time. They must constantly adapt to changes from Acceptance. They have to watch for breaking changes and maintain backward compatibility. It’s tough. But there’s a silver lining - if their Context is the last in the chain, they can evolve freely without worrying about others depending on them.
Summary
There’s no single best place to be - Upstream or Downstream. It depends on the people involved and the trade-offs they’re willing to accept. Some prefer leading with autonomy, others are comfortable adapting with flexibility. Ideally, let teams choose what suits them best.