Why Service Boundaries Fail: Aligning Business Rules, Data Ownership & Team Topology

In a previous article on overall architecture, the author emphasized that architecture design must start from business goals, quality requirements, and failure impact—not from microservices, message queues, or databases. Once high-level constraints are set, the next question is how to divide services.

Many architecture efforts jump straight to diagramming: Order Service, Refund Service, Payment Service, Notification Service—each business noun gets a box connected by arrows. But the real difficulty of service division is not drawing boxes; it is answering why each box should be independent, which business rules and data it owns, who is responsible long-term, and who recovers when it fails.

Distinguish Four Often-Conflated Boundaries

Before discussing service division, four concepts must be separated:

Business boundary – the scope of a coherent set of business rules and language.

Module boundary – a code-level separation within a single deployable unit.

Service boundary – an independently deployable unit with its own runtime.

Deployment boundary – the physical process/container separation.

A module can have a clear business boundary yet be deployed with others; a service may be independently deployed but still share a database, release together, or be operated by another team. Code, process, and responsibility are three different boundaries. Independent deployment solves only one layer and does not automatically bring independent evolution. Service division should not start from “how many processes to split” but from confirming which boundaries truly exist, then deciding whether to make them independent deployment units.

Refund Case Study: At Least Three Division Options

Consider refund processing: user submits request, system validates order state, calls payment channel for refund, then notifies user. Functionally, a “Refund Service” seems natural, but before deciding, compare three approaches:

Internal logic within Order – refund rules live inside the order module.

Independent Refund module – refund rules, state, and interfaces are separated from Order code but deployed together.

Independent Refund service – separate process, database, deployment pipeline, and team.

If the team is small, refund rules change frequently, and Order and Refund need strong consistency, the author prefers a well-bounded independent module—not an immediate microservice. This preserves the business boundary while staging “business independence” and “deployment independence” as two phases: first extract refund rules, state, and interfaces from Order code; later, based on change velocity, capacity needs, and team ownership, decide whether to split the process.

Independent service becomes meaningful only when signals appear:

Refund rules, audit flows, and channel adapters form a standalone business capability.

Refund and Order release cadences diverge significantly.

Refund workload, resource consumption, or availability targets need independent control.

A stable team can own end-to-end responsibility from development to operations.

Data ownership and cross-boundary contracts are clearly definable.

Service division evolves with business and responsibility maturity; it is rarely settled by a one-time “split or not” decision.

Business Boundaries Are Not Noun-Based Cuts

Domain-Driven Design uses “business capability” and “bounded context” to identify boundaries. Boundaries should form around a relatively complete set of business rules, language, and state changes. Refund touches Order, Payment, and After-sales, but “involvement” ≠ “ownership.”

Ownership matters more than call frequency. If Refund Service can directly modify Order status, Payment Service can modify Refund records, and Notification Service infers business results from multiple tables, the boxes are separated but business rules remain scattered.

Better: each boundary maintains its own rules and state, requests other capabilities via explicit contracts, or publishes facts that have already occurred. Cross-boundary information can be passed, but decision authority must not drift silently along call chains.

To judge whether a rule set belongs in one boundary, ask:

Do they change around the same business goal?

Do they share the same business language and constraints?

Must a state change maintain consistency across these rules simultaneously?

When errors occur, is the same accountable party responsible for judgment and recovery?

After splitting, are the added contract and consistency costs justified?

Without answers, splitting by entity names or table counts merely transforms code coupling into network coupling.

Data Ownership: The Hardest Boundary to Fake

A direct test of true service independence is: who holds write authority? Suppose Refund is a separate service but still directly updates Order’s status column in the Order database; Order Service also writes to Refund tables. This appears to save an interface call but actually lets two services co-own the same state.

Shared writes cause:

Schema changes require coordinated modifications across services.

Business rules cannot be centrally enforced when bypassing APIs.

Data discrepancies become untraceable to the originating service.

A service cannot independently migrate, release, or roll back.

Responsible teams cannot independently guarantee data integrity.

Data boundaries do not require each service to own a separate physical database instance, nor forbid other systems from reading. The key is unambiguous authoritative write and rule ownership.

In the refund example: Refund capability owns refund applications and processing states; Order capability owns order status; Payment capability owns payment transactions and channel receipts. Payment executes and records channel fund results; Refund updates refund state and publishes completion facts; Order then updates its own status per its rules. Cross-boundary queries can use APIs, event replicas, or analytical stores—but never grant multiple services write access to the same business data for query convenience.

Team Topology Continuously Reshapes Service Shape

Conway’s Law reminds us that system communication structures mirror organizational communication structures. Architecture diagrams need not mechanically copy org charts, but service boundaries that persistently contradict team collaboration patterns will eventually be reconnected by excessive meetings, handovers, and shared code.

If Order, Refund, and Payment are owned by three teams yet every refund change requires a coordinated three-team release, the so-called independent services deliver no independent delivery. Conversely, if a five-person team maintains twenty microservices—each needing its own pipeline, alerts, on-call, and dependency upgrades—the team cannot truly own those boundaries. The typical outcome: many services, but batch releases, shared on-call, and unified troubleshooting.

Therefore, team boundaries must be designed alongside business boundaries:

A team should ideally own an end-to-end slice that can produce a business outcome.

Service count and operational complexity must not exceed the team’s long-term maintenance capacity.

Platform teams provide common capabilities (release, observability, security) but do not assume runtime results or business risks for service teams.

Cross-team contracts need explicit maintainers, compatibility rules, and upgrade paths.

After failures, resolution must not depend on ad-hoc searches for “the person who really knows this code.”

Team topology is not a post-hoc staffing arrangement; it is a design constraint that determines whether service boundaries can endure.

An Independent Service Must Close Four Responsibility Loops

After drawing a service as an independent box, verify that four responsibility types are closed:

Business responsibility – owns rules, decisions, and state changes.

Data responsibility – owns authoritative write, schema evolution, and integrity.

Runtime responsibility – has SLOs, alert recipients, and recovery owners; not just a deployment artifact.

Evolution responsibility – can change contracts without forcing synchronized releases elsewhere.

If a service has only a code repo and deployment unit but lacks SLOs, alert owners, and recovery owners, it has a deployment boundary but no runtime boundary. If a team only implements features and hands off to a central ops team for all production issues, it cannot correct design from production feedback. Production ownership does not mean developers do all platform work; it means the service team retains ownership of runtime outcomes.

These responsibilities land at three levels:

Architecture/governance roles define business boundaries, data ownership, and cross-service contracts.

Platform teams supply unified release, observability, traffic governance, and service catalog.

Service teams continuously own rules, SLOs, alert response, and recovery; business owners acknowledge high-risk residual risks.

Five Hidden Couplings That Re-Glue Independent Services

When reviewing service boundaries, the author checks five coupling types:

Shared database writes – multiple services writing to the same tables.

Synchronous long call chains – deep request-response trees that create temporal coupling.

Shared business libraries – common jars/packages that embed business logic across services.

Joint deployments – services that must be released together.

Responsibility handovers – unclear ownership leading to ticket ping-pong.

These couplings are not always eliminable. At small scale, shared deployment and local calls may be the rational choice. The danger is claiming independence while ignoring existing couplings without a plan for who addresses them.

For couplings that cannot be removed immediately, document impact scope, owner, and exit criteria. Example: a shared database as a migration-phase temporary state, but with clear table-to-writer mapping, a timeline to stop cross-service writes, and proof of migration completion.

Boundary Validity Must Be Verified by Evidence

Service boundaries are not architectural assertions that become true once drawn.

Verification Criteria and Evidence Sources

Business rules ownership clear – Verification goal: Is each rule maintained and enforced by only one boundary? Evidence sources: Domain models, use-case inventories, architecture reviews.

Data ownership explicit – Verification goal: Are there cross-service direct writes or contract-bypassing updates? Evidence sources: Data lineage, DB permissions, dependency checks.

Service can evolve independently – Verification goal: Do contract changes require other services to release in lockstep? Evidence sources: Compatibility tests, release records, change failure rates.

Service team can own long-term – Verification goal: Are alerts, recovery, and upgrades backed by a stable responsible party? Evidence sources: Service catalog, on-call logs, runbooks.

Split benefits exceed costs – Verification goal: Have delivery, scaling, or isolation actually improved? Evidence sources: Lead times, capacity data, failure blast radius.

If after splitting Refund, releases still need Order team coordination, databases are still written by both sides, and incidents bounce between teams, the boundary design has not succeeded—even if the service is independently deployed.

When data ownership is disputed, cross-team responsibility cannot be pinned down, or splitting requires simultaneous changes to multiple critical systems, the decision must not be made by an architect or agent alone. The correct state is to pause implementation and have business owners, system leads, and runtime owners jointly confirm boundaries and risks.

When Not to Keep Splitting Services

The following signals usually indicate over-engineering:

Services only forward requests without owning logic.

Every change requires coordinated modifications across multiple services.

No dedicated on-call; services are unattended.

Excessive compensation/rollback logic to handle distributed consistency.

No measurable isolation benefit (scaling, failure containment, team autonomy).

Splitting only because “microservices are popular.”

A modular monolith is not a backward stage before microservices. For businesses still exploring, with limited team size, or high strong-consistency needs, a well-bounded modular monolith often validates business design more easily and can be incrementally split once boundaries mature.

The ultimate comparison is not service count, but whether boundary benefits—delivery speed, scaling flexibility, fault isolation, team autonomy—cover the long-term costs of distributed communication, state consistency, deployment, and operations.

Summary

Service division is not putting business nouns into boxes, nor deciding microservice count first and then hunting for responsibilities.

Effective service boundaries require joint support from business rules, data ownership, change cadence, and team responsibility. Business boundaries can be established first inside modules; only when independent deployment, scaling, fault isolation, or team autonomy benefits are clearly sufficient should they become service boundaries.

<ol><li><code>First make responsibility boundaries hold,</code></li><li><code>then decide whether deployment boundaries should be independent.</code></li></ol>

The next article will go inside the service: even after services are split, business rules may still be controlled by databases, web frameworks, and messaging components. Once physical boundaries exist, how should internal policies, use cases, adapters, and dependency directions be designed?