How does a Service Layer typically manage the transaction boundary for a use case that touches several different domain objects or repositories, and what goes wrong if that boundary is drawn in the wrong place?

## One transaction per use case The core mechanical idea is: **one transaction per use case**, demarcated at the Service Layer method boundary rather than anywhere lower in the call stack. Concretely, when a client calls `OrderService.placeOrder(...)`, a transaction is started (often by a framework interceptor wrapping the annotated method, e.g. Spring's `@Transactional`, or manually via a `begin()`/`commit()`/`rollback()` block at the top of the method) before the method touches any repository, and it is committed only after every repository call the method makes has succeeded, or rolled back if any exception propagates out. Everything the method does in between happens inside that single **unit of work**: - loading the Customer, - loading the Cart, - decrementing Inventory, - creating and saving the Order, - appending to an audit log. If any single step fails (say, inventory decrement throws because stock ran out), the database driver rolls back every change made so far in that transaction, so you never end up with an Order row persisted but no matching inventory adjustment, or vice versa. ## Why the boundary sits here The reason this responsibility sits at the Service Layer specifically, rather than in the domain objects or in the repository/DAO layer, comes back to **layering discipline**. - **Domain objects** are kept persistence-ignorant by design — an `Order` entity shouldn't know what a database transaction is, because that would couple pure business logic to infrastructure and make it hard to unit test without a real database. - **Repositories**, meanwhile, typically operate one aggregate at a time and don't know about the other repositories a given use case might also need to touch, so they can't correctly decide when the whole use case's work is complete. - **The Service Layer method** is the one place that both knows the full scope of the use case (it's the one orchestrating calls to multiple repositories/domain objects) and sits above the domain model in the dependency direction, so it's the natural — often the only sensible — place to say 'this transaction starts here and ends here.' ## The trade-off is granularity The trade-off is granularity, and getting it wrong in either direction causes real production problems. | Boundary | What it costs you | |---|---| | **Too wide** | connection-pool exhaustion and lock contention, because a slow external call sits inside the open transaction | | **Too narrow** | partial-failure risk and inconsistent state between the commits | ### Too wide Drawing the transaction boundary too wide is the more common mistake in growing codebases: a Service Layer method that, in addition to its core database work, also makes a synchronous call to an external payment gateway or sends an email, all inside the same open transaction. This holds a database connection (and often row-level locks) open for however long that external call takes, which under load causes connection-pool exhaustion and lock contention — other requests trying to touch the same rows queue up waiting for locks that are held not because of database work but because of a slow HTTP call to a third party sitting inside the transaction. The fix is usually to do the external call either before opening the transaction, after committing it, or to decouple it entirely via an outbox/event mechanism so the transaction only covers the local database work. ### Too narrow Drawing the boundary too narrow is the opposite failure: splitting one logical use case into several small transactions, each committing independently — for instance, committing the inventory decrement in one transaction and the Order creation in a separate transaction. If the process crashes, or an exception occurs, between those two commits, you're left with inconsistent state: inventory was decremented but no order exists to justify it. This reintroduces exactly the partial-failure risk that transaction demarcation exists to prevent, and it quietly pushes the coordination problem onto callers or onto ad hoc reconciliation jobs, which is a much worse place for it to live than a single properly-scoped transaction. ## Moving money between two accounts A concrete real-world scenario: a banking application's 'transferFunds' use case must debit one account and credit another. If `TransferService.transfer(fromId, toId, amount)` is implemented as two separate service calls — `debit(fromId, amount)` then `credit(toId, amount)` — each with its own transaction, a crash between the two calls leaves money debited from one account with no corresponding credit anywhere, an accounting discrepancy that's expensive to detect and reconcile after the fact. Implementing it as a single Service Layer method wrapping both operations in one transaction guarantees that either both the debit and credit happen, or neither does — that atomicity guarantee is the entire reason banking systems insist on this exact 'one Service Layer method, one transaction' shape for money-movement use cases, and it's a standard example in transaction-management literature for precisely this reason. ## When one local transaction cannot cover it One more subtlety worth naming: this pattern applies cleanly within a single database, but if a use case must coordinate across two independently-transactional resources (two separate databases, or a database plus a message queue), a single local ACID transaction can't span both, and the Service Layer needs a different coordination strategy such as the outbox pattern or a saga, rather than pretending one `@Transactional` annotation solves distributed consistency.