Designing Microservices Boundaries with Claude: Finding Bounded Contexts

1. Why the boundary is the hardest decision in the system

Unlike a naming conflict in a codebase or a messy class hierarchy, a wrong service boundary cannot be fixed with a single refactoring commit. Once two services talk over a public API, live in separate repositories, and are operated by separate teams, every boundary shift turns into a migration involving versioning, transition phases, and coordination across team lines. The cost of a wrong cut often shows up only months after the decision, once teams need to constantly synchronize across service boundaries.

That is exactly why extra effort up front pays off. Claude can act as a fast conversation partner in this phase, one that structures domain knowledge, plays out options, and asks the questions that get skipped in day-to-day work. The right expectation matters here: Claude does not hand over a finished architecture to rubber-stamp, it works best iteratively, fed with real domain knowledge from the team and critically checked at every step.

2. Deriving bounded contexts from the business domain

The clean starting point for a microservices cut is not the technical infrastructure but the domain-driven design concept of a bounded context: a business area where a term like Customer or Order carries one consistent, self-contained meaning. Claude can help derive candidate context boundaries from a description of business processes, especially when given explicit ubiquitous-language terms, process flows, and known inconsistencies between departments.

The quality of the prompt is what determines the result: instead of asking for a generic microservices split, feed Claude a domain glossary, a list of existing database tables with their relationships, and a short description of where terms like Product are already used inconsistently across the company. Those semantic fractures are often the most reliable signal for a genuine bounded-context boundary.

# Example prompt for Claude Code: deriving bounded contexts from domain knowledge
claude "Here is our domain glossary (glossary.md) and a list of core
processes (processes.md) for our B2B wholesale business. Identify
candidate bounded contexts following DDD. For each candidate:
- Core responsibility in one sentence
- Which entities/aggregates belong there
- Where the term 'Customer' is used with different meanings
- Open questions I need to clarify with the business side
Do NOT propose a finished microservices architecture, only the business
boundaries as a discussion basis.

3. Trade-off: when the cut is too fine grained

An overly fine cut typically results when technical rather than business criteria drive the split, for example one service per database table. The outcome is often a distributed monolith: many small services that need to talk synchronously on nearly every request, driving up latency while letting errors propagate across service boundaries. Chatty services of this kind lose the actual benefits of microservices, namely independent deployability and failure isolation, while still carrying the full operational overhead of a distributed system.

Claude can help spot such patterns when given a list of planned services along with their call relationships and asked explicitly to flag synchronous call chains longer than two hops. Such chains are a strong warning sign that related business logic was artificially split apart and should instead be modeled as a single service or through asynchronous events.

4. Trade-off: when the cut is too coarse grained

At the other end of the spectrum sits the overly coarse cut, where several business-independent responsibilities end up in a single service, for example order processing and invoicing combined. This does not first show up as a performance problem but as deploy coupling: a team that only wants to change invoicing logic has to test and ship the entire service, including all order functionality untouched by that change. Release cycles slow down, and ownership of bugs blurs between teams.

A useful signal Claude can surface during review is asking about independent reasons for change at the service level, in the spirit of the single-responsibility principle: if two functional areas of a service change for different business reasons and at different times, that is an indicator of an overly coarse cut, even if both areas look tightly coupled technically.

5. Claude as a sparring partner, not a decision maker

The most important methodological point when working with Claude on architecture questions is the division of roles: Claude generates options, surfaces implicit assumptions, and asks the questions that get missed in everyday work, but it does not make the final call. Architecture decisions carry political, organizational, and historical components Claude has no access to, such as which team already has experience with a given technology or which area is scheduled to be spun off in six months.

In practice, a useful pattern is deliberately using Claude as devil's advocate: after a first draft, ask Claude to hunt specifically for counterarguments against the chosen cut, such as hidden coupling or data consistency problems across service boundaries. This role as a critical reviewer, not a decider, often delivers more value than a direct request for a finished architecture.

# Deliberately using Claude as a critical reviewer, not a decision maker
claude "Here is our architecture draft for 6 services (architecture.md).
Play devil's advocate: find the three strongest counterarguments against
this cut. Focus on:
- Hidden data coupling between services
- Transaction boundaries that would span multiple services
- Cases where two services almost always change together
Do NOT make a decision, only deliver the counterarguments with reasoning.

6. How much context Claude needs for solid suggestions

A generic prompt like design a microservices architecture for an online shop produces generic textbook answers that rarely fit the actual organization. Solid results only emerge once Claude gets access to real artifacts: existing data models, current team structure, historically grown coupling, and known pain points in the current system. Without that context, Claude extrapolates from general patterns that sound plausible but can miss the actual domain.

An often underestimated factor is Conway's Law: an organization's communication structure inevitably shows up in its software architecture. A service cut that contradicts the existing team structure, for example because one service would need to be maintained by three different teams, rarely works in practice, no matter how clean it looks on paper from a business modeling perspective. This organizational reality should be given to Claude explicitly as a constraint.

7. Practical example: breaking down an e-commerce domain

This is easiest to show with an order processing example. Instead of a single OrderService that bundles order capture, payment processing, shipping, and returns, a discussion with Claude can typically surface four distinguishable business contexts: order management as the core of order capture, payment as a standalone context with its own consistency requirements due to regulatory constraints, fulfillment for warehousing and shipping, and returns as its own process with a different lifecycle than the original order.

What matters in this example is that Claude does not just propose the boundaries but makes the reasoning transparent: payment is often split out as its own service because different compliance requirements such as PCI-DSS apply there and a different team with specialized knowledge owns it, not primarily for technical scaling reasons. That kind of reasoning can be validated with the business side, whereas a plain diagram without justification rarely can be.

8. A review checklist for Claude during architecture checks

Instead of re-explaining what matters to Claude for every single review, a fixed checklist reused repeatedly as a prompt basis pays off: clear data ownership per service, no shared database between services, clear transaction boundaries without distributed two-phase commits, synchronous call chains under three hops, and one team owning full responsibility for each service. These criteria can be baked into a reusable prompt template applied to every new architecture draft.

Such a checklist also makes Claude's feedback more consistent across different reviewers and points in time, since nobody has to improvise which criteria even matter in a given session. At the same time, the checklist stays a living document that should be extended after every major architecture incident, for example an expensive migration caused by a wrong cut, with the lesson learned.

9. Limits: what Claude cannot know

As helpful as Claude is at structuring and questioning, it knows neither the actual team politics nor informal power dynamics, nor the planned reorganization that will redistribute responsibilities in three months. An architecture proposal that looks clean on paper from a business perspective can fail on exactly those organizational realities nobody writes into a prompt, because they are informal and often unspoken.

Claude equally does not know the actual load distribution, the real growth of individual business areas, or unwritten legacy knowledge that only lives in the heads of experienced developers. The cut should therefore always be treated as an iterative dialogue, where Claude supplies options and counterarguments while the final decision is made by the team and aligned with the stakeholders of the affected business areas.

10. Summary

11. FAQ: Microservices Boundaries with Claude: Key Questions