Service Decomposition & Boundaries

Group services around business functions like 'Orders', each owning its own logic and data end to end. Splitting by technical layer (UI service, logic service, DB service) instead forces every feature to touch several services at once.

It's when you've split code into separate services but they're still so tightly tied together that you can't deploy or change one without touching the others - you get all the complexity of microservices with none of the independence.

A bounded context is the area of the business where a word like "Order" has exactly one meaning. Building a service per bounded context keeps each service's data model and vocabulary consistent, instead of forcing every team to agree on one giant shared meaning for every term.

A nanoservice is a service split so small (like one endpoint) that it does barely any real work but still pays the full cost of being a separate service - network calls, its own database, deployment pipeline, on-call rotation. That overhead usually costs more than it saves.

Split it into an adapter (talks the provider's protocol/SDK) and a translator (converts its data into your own domain types). The boundary sits exactly where the provider's names, codes, or shapes would otherwise leak into your business logic.

A bounded context is where one business term has one consistent meaning (e.g., 'Customer' differs between Billing and Support). Match each service to one context; crossing that boundary causes inconsistent meanings and constant translation code between services.

Build the new Inventory service beside the old monolith, redirect traffic bit by bit through a router. Once the old code sees no traffic, delete it — like a strangler fig vine replacing host tree.

The database schema becomes a hidden shared contract - if one service changes a table, every other service touching that table can break, so you can't change or deploy them independently anymore.

Temporal coupling means all three services must be up and responding fast at the same moment for the request to succeed - if C gets slow, B waits on it, then A waits on B, and the slowdown ripples backward through the whole chain.

An aggregate is a group of objects that must stay consistent together, like an order and its line items. If you split it across two services, you can't guarantee both parts update together, so the data can end up in an invalid, inconsistent state.

This is called 'chatty' service communication - too many small back-and-forth network calls needed to do one piece of work. It usually means services were split too finely along lines that don't match how work actually flows, so simple operations require calling many of them in sequence. Fixes include combining related services, batching calls, or having one service own more of the workflow.

An entity service is a microservice built around one database table (like 'Customer' or 'Order') that just exposes create/read/update/delete endpoints for that table, with no real business logic. It looks like a clean split by 'noun,' but it pushes all the actual decision-making into whichever caller uses it, so business logic ends up duplicated or scattered across many services instead of owned by one.

This is a distributed monolith: separate services still tightly coupled (shared code, chatty synchronous calls, or a shared database), so you can't deploy them independently — all of microservices' overhead, none of the benefit.

When one service depends on another's data, you can either just copy the upstream's model as-is (fast but fragile), or build a small translation layer that converts it into your own local model (more work but protects you from their changes). DDD calls these patterns things like "Conformist" and "Anti-Corruption Layer."

Cohesion means things that change together and belong together should live in the same service. Coupling means how tangled services are with each other. You want high cohesion inside a service and low coupling between services. Getting the size right means grouping things that truly belong together, and not more.

The Pricing team is running an Open-Host Service with a Published Language: a stable, documented public contract instead of exposing its raw internal model. Consumers can then integrate against that contract directly, needing a much thinner ACL - or sometimes none - because the translation work already happened once, upstream.

Give each piece of data one owning service that's the source of truth for writes. Others call the owner for occasional fresh reads, or keep a replicated copy, updated via events, for frequent reads or to stay available if the owner is down.

Look at the release calendar and incident history: if services almost always deploy together, or one service's outage always drags others down with it, that's the tell - you don't need to read the code to see the coupling.

Figure out which service should really own each piece of data and behavior, move that ownership over step by step, replace direct cross-service database reads with API calls or events, and only split each piece of data into its own database once nothing else touches it directly anymore.

Sometimes it's fine to put two related but minor business areas in one service if they're small and rarely change, to avoid running lots of tiny services. But splitting one business area's logic across several services usually causes trouble, because it breaks up something that should stay together.

Too coarse means services are basically small monoliths - hard to scale or deploy independently, one team's bug blocks everyone. Too fine means way too many tiny services - huge operational overhead, slow chatty calls, hard to reason about the whole system. The right size depends on team size, how independently pieces need to change, and how much operational complexity the team can actually handle.

An ACL isn't free - it's worth it when you can't influence or trust the upstream model, e.g. legacy, third-party, or unstable systems. If you can jointly evolve the API with a cooperative team, negotiating a shared contract is usually cheaper and better than building a translation layer against a moving target.

This is over-decomposition, or 'nanoservices' — splitting so finely that running each piece (deploys, monitoring, network calls) costs more than the benefit. Right size is roughly 'one team, one business capability,' not 'one service per field.'

When two services always break together, it usually means they were never really separate business areas to begin with, or the line between them was drawn in the wrong place. You'd look at what concept they secretly share, then either merge them back into one service, move the shared idea fully into one of them, or add a clear translation step between them.

Granularity isn't a one-time decision - as a system and its teams grow, the 'right' size for a service changes. You split a service when a real, measurable reason shows up (different scaling needs, a new team owning part of it, slow deploys from unrelated changes). You merge services back when they always change together and the split is just adding overhead without any benefit.

It's translating not just data shapes but integration style - turning a synchronous poll-based system into an event stream. This adds new failure risks: missed or duplicate events, detection lag between polls, and the ACL now holding state (what it last saw) instead of being stateless.

Not always - during a migration, having some temporary shared coupling can be the safer path. It becomes a real problem when it's permanent and when the teams responsible for the coupled services aren't structured to fix it.