Consider transferring money between two Account aggregates, where withdrawing from a source account and depositing into a target account must jointly enforce a rule like 'the source must have sufficient funds.' Walk through why this is best modeled as a Domain Service rather than as a method directly on the Account entity, and what trade-offs that choice introduces.

## Where the responsibility line falls The core design tension in this scenario is where to draw the responsibility line between 'what one `Account` entity protects on its own' and 'what needs a coordinator that understands both accounts at once.' An `Account` aggregate's job, in DDD terms, is to guard its own invariants - rules that must always hold true about its own state, like 'balance never goes negative.' That's naturally expressed as two methods on `Account` itself: - `withdraw(Money amount)`, which checks the balance is sufficient and decrements it - and `deposit(Money amount)`, which increments it (and perhaps checks a maximum-balance rule) Neither of these needs any awareness that a transfer is happening; each just protects its own aggregate's state, which is exactly the level of responsibility an aggregate is supposed to have. ## Why the transfer itself belongs elsewhere The transfer itself, though, is a rule that spans two aggregates: 'the source account must have sufficient funds' is meaningful only in the context of the pairing, and the action of moving money is really one business event, not two independent ones that happen to occur together. If you tried to express this as `Account.transferTo(Account target, Money amount)`, the source `Account` would need a live reference to another aggregate root and would be responsible for calling mutating methods on it: - this **violates the standard DDD guidance** that aggregates should reference each other by identity (an `AccountId`) rather than by direct object reference, precisely so that one aggregate never reaches in and mutates another's internals directly - it also means the `Account` entity's **test surface and reasoning burden balloon**: instead of testing 'withdraw enforces sufficient funds' in isolation, you'd have to test the two-account interaction as part of Account's own unit tests, which muddies what the entity is actually responsible for ## The cleaner design The cleaner design keeps `Account` narrow (withdraw and deposit, each enforcing only its own local rule) and introduces a `FundsTransferService` domain service that is given both `Account` aggregates (loaded by the caller, typically an application service) and the amount, and it does exactly three things: 1. check the cross-account precondition (source has sufficient funds) 2. call `source.withdraw(amount)` 3. then call `target.deposit(amount)` This is a textbook example of the pattern - it's stateless, named after the exact business process it performs, and holds the one piece of logic ('sufficient funds, across this specific pairing') that doesn't belong to either account individually. ## The trade-off: atomicity and failure handling The trade-off this design introduces is around atomicity and failure handling. In DDD's typical guidance, a single transaction should touch at most one aggregate, because that's the unit the aggregate boundary is designed to protect. A transfer necessarily mutates two aggregates, so something above the pure domain-service call has to decide how the two mutations become consistent together. | Where it runs | How the two mutations are made consistent | |---|---| | **In a single-database monolith** | the pragmatic and common answer is to wrap both saves in one database transaction managed by the calling application service - which technically bends the one-aggregate-per-transaction guideline but is an accepted, well-understood compromise for two aggregates in the same bounded context and the same database | | **In a distributed system** | where the two accounts might live in different services or databases, that shortcut isn't available, and the transfer has to be modeled explicitly as a multi-step process with compensation: withdraw first, then attempt deposit, and if the deposit fails, run a compensating action that credits the amount back to the source - the saga pattern - or use an eventually-consistent approach where the transfer request is recorded as an event and the two mutations are applied asynchronously with reconciliation for failures | ## The failure mode to watch for The failure mode to watch for in either version is a transfer service that performs the withdrawal and the deposit as two entirely separate, uncoordinated operations with no shared transaction and no compensation logic - if the process crashes between the two steps, or the second call throws, money vanishes from the source account without ever appearing in the target, which is exactly the kind of defect that's invisible in happy-path testing and expensive when it surfaces in production (a customer support ticket about a missing balance, reconciled by hand). A well-designed `FundsTransferService` makes this failure mode visible in its own structure: it either wraps both mutations in one transaction when that's available, or it explicitly documents and implements the compensating step when it isn't, rather than silently hoping both calls succeed. This exact scenario - fund transfer as the paradigm case for a domain service - originates in Eric Evans' original description of the pattern and remains one of the clearest illustrations of why domain services exist at all: some business rules are inherently about a relationship between two things, not a property of either one alone.