You're modeling a 'FundsTransfer' operation between two Account aggregates in a banking domain. Walk through the reasoning for why this operation should become a domain service rather than a method on the Account entity, and what the domain service's method signature and statelessness constraints should look like.

## Two concepts to unpack The account-transfer example is one of the canonical illustrations of when a domain service is the right tool, and unpacking why requires two DDD concepts: - **aggregate boundaries** - **business logic ownership** ## Aggregate boundaries An aggregate is a cluster of objects (here, a single `Account` with its balance and transaction history) treated as one consistency boundary — the rule of thumb in tactical DDD is that a single transaction should load and modify exactly one aggregate instance, because aggregates are the unit across which invariants are guaranteed to be enforced atomically, and letting one transaction mutate two aggregate instances directly makes it easy to violate that guarantee under concurrent access. Given that rule, a transfer between `Account` A and `Account` B genuinely can't be "a method on `Account`" in the naive sense, because: - it needs to mutate two aggregate instances as a coordinated pair - and it isn't obviously A's responsibility versus B's; there's no principled reason to hang the whole operation off one side ## The domain service that owns the operation This is exactly the situation a domain service exists for: a business operation that is real domain logic (it enforces rules — sufficient funds, maybe a daily transfer limit, maybe currency conversion) but doesn't have a single natural owner among the entities/aggregates involved. So you introduce `FundsTransferService` whose method takes both aggregates plus the transfer amount as explicit parameters: `transfer(source: Account, target: Account, amount: Money): TransferResult`. Inside, the service still delegates as much as possible to the aggregates themselves: - it calls `source.withdraw(amount)`, which enforces the aggregate's own invariant (can't go below zero, or below an overdraft limit) and throws or returns a failure if violated - and `target.deposit(amount)`, which enforces target-side invariants (e.g., account must be active, not frozen) The domain service's own added logic is the coordination and any transfer-specific rule that isn't naturally either account's business — for instance, "a transfer above a certain amount requires additional compliance flagging" is a rule about the transfer as a concept, not about either account individually, so it lives in the service. ## Statelessness, and the two reasons for it Statelessness is the other half of the design. A domain service should hold no mutable instance fields that persist between calls — every call is a pure function of its explicit arguments (plus any constant configuration injected at construction, like a `PricingPolicy` object, which is fine as long as it doesn't change per-call). This matters for two operational reasons. - **First, thread safety**: if the service is a long-lived singleton and it held per-request state, concurrent requests would corrupt each other's data; statelessness sidesteps this entirely, no locking needed. - **Second, testability**: because the only inputs are the explicit parameters and the only outputs are the return value (plus mutations to the passed-in aggregates), a unit test can construct two in-memory `Account` instances, call `transfer`, and assert on their resulting balances — no database, no framework context, no mocking required. This is a meaningful trade-off versus embedding the transfer logic in a repository or application service that already has a database connection open: the domain service version is slightly slower to write initially (you have to explicitly pass everything in) but dramatically faster and more reliable to test, and it's reusable from any orchestration context — a REST endpoint, a scheduled batch job, or an event handler — without duplicating logic. ## Who actually persists the two accounts Who actually persists the two accounts is the important boundary to get right: the domain service returns the mutated (or new) aggregate instances but does not call a repository's save method itself. That's the calling application service's job: 1. it loads both accounts via their repositories 2. calls `fundsTransferService.transfer(source, target, amount)` inside a single database transaction 3. then saves both accounts and commits This keeps the domain service infrastructure-free and keeps the transaction boundary exactly where it belongs — in the application layer, wrapping both the domain-service call and the two saves as one atomic unit of work. ## The failure mode to watch for The failure mode to watch for: teams sometimes let the domain service reach into a repository directly ("let me just load the target account by ID inside the transfer service to save the caller a lookup"), which blurs the transaction boundary — now the service is doing I/O the application service doesn't control, and it becomes hard to guarantee both accounts are saved in the same transaction, or to unit-test the service without a real or mocked repository. A real-world instance of this exact pattern shows up in most textbook explanations of DDD tactical patterns — Eric Evans' original Domain-Driven Design book uses funds transfer as its running domain-service example precisely because it cleanly demonstrates the "operation with no natural owning entity" case.