You're designing a 'TransferFunds' use case between two bank accounts using Hexagonal Architecture. Walk through what the driving port, the application core's responsibilities, and the driven ports would be, and explain why the application core is described as the 'dependency anchor' of the whole design.

## The dependency anchor The "dependency anchor" framing captures a specific structural property: draw every dependency arrow in a hexagonal system, and every single one of them points toward the application core, never away from it. This is true for both families of adapters, and the TransferFunds example makes both directions concrete. - **On the driving side**, a REST controller adapter depends on the `TransferFundsUseCase` port — it imports that interface, builds a `TransferCommand` from the incoming HTTP request body, and calls `transfer(command)`. The core's concrete implementation of that interface lives inside the core module and is the only thing that knows how the business rule actually executes; the controller has zero knowledge of how balances are validated or stored. - **On the driven side**, the relationship is the same directionally even though the runtime call flows the other way: the core defines an `AccountRepository` port with methods like `findById(accountId): Account` and `save(account: Account)`, and a database-backed adapter implementing that interface depends on (imports) the core's port definition to know what contract to fulfill. In both cases, the arrow of source-code dependency points at the core; only the arrow of runtime control flow differs (driving adapters call into the core, the core calls out to driven adapters, but "calls out to" does not mean "depends on" — the core calls a port it owns, not the adapter's concrete class). | Adapter side | Source-code dependency | Runtime control flow | |---|---|---| | Driving (a REST controller) | imports the `TransferFundsUseCase` port | calls into the core | | Driven (a database-backed adapter) | imports the core's `AccountRepository` port definition | the core calls out to it | ## Inside the core Inside the core, the actual work for TransferFunds is pure business logic expressed against domain types with no infrastructure awareness: 1. load account A and account B via `AccountRepository`; 2. verify both are found and active; 3. verify account A's balance is greater than or equal to the transfer amount (and any other invariant, e.g. a daily limit check against a value object like `Money`); 4. compute new balances; 5. and — critically for a financial operation — decide how the two writes are made consistent. In a naive layered design, this consistency decision often gets pushed down implicitly to whatever the persistence framework's transaction manager happens to do; in a well-designed hexagonal core, the invariant that both balances change together or neither does is something the core is explicit about, even though the actual transactional mechanism — a database transaction, a saga, a two-phase commit — is an adapter concern. This is a subtlety worth naming: a poorly drawn `AccountRepository` port that only exposes `save(single account)` can make it hard for the core to express "save these two updates atomically" without leaking transaction management into the core; a well-drawn port might instead expose `saveTransfer(fromAccount, toAccount)` as one coherent, atomically-implied operation, keeping the atomicity requirement expressed at the core level while its mechanism stays in the adapter. ## Two properties that matter operationally Being the dependency anchor gives the core two properties that matter operationally. 1. **First, it can be understood in total isolation.** A reviewer or new hire can read the core module, understand every business rule for money transfers, and never need to open a database migration file or an HTTP routing config to know what the system does. 2. **Second, it can be replaced-around without being touched.** Swapping the REST API for a gRPC API (new driving adapter), or one database vendor for another (new driven adapter), touches zero lines inside the core, because neither adapter was ever a dependency of it. This is the payoff that offsets the indirection tax specifically for domains with real business complexity — a funds-transfer rule set is exactly the kind of logic worth insulating this way, unlike a trivial CRUD "update user's display name" endpoint where the anchor pattern's ceremony rarely earns its keep. ## The failure mode specific to this design The failure mode specific to this design task is drawing the driven port at the wrong granularity relative to the actual business invariant, as illustrated above with the two-write atomicity problem. Get the port shape wrong and either: - the core silently trusts an adapter to do something it never asked for, a landmine for future adapter authors who don't know the invariant exists; or - the core is forced to leak a transactional concept like "begin transaction" across the port boundary to compensate, which erodes the very isolation the anchor pattern exists to provide. A real-world parallel: banking core-systems built around a ledger-service core commonly express a transfer as a single `postDoubleEntry(debit, credit)` operation at the port level specifically so the atomicity invariant is a first-class part of the contract, rather than something callers must remember to arrange themselves.