Duncan Jones

**Query functions** - GetQueryState - Get the state of the given query instance - CompareQueries - Compare the outcome of two query instances (for "what has changed" analysis)

Each query will need a **Query Processing Requested** event to trigger any downstream processing - for example you might have a "cache watcher" that just responds with a cached value...

This could also demonstrate the idea of the causation identifier which would link the source withdrawal and the target deposit to the transfer command identifier.

## Events:- - Transfer initiated - Source funds withdrawn - Target funds deposited - Refund initiated - Source funds refunded - Refund failed

## Projections:- - Transfer State (Initiated -> Funded -> Transferred / Transfer Failed -> Refunded -> Refund failed)

## Classifications:- - Failed refunds (these might require manual intervention)

## Commands:- - Transfer money - Cancel in-progress transfer

## Queries:- - GetTransferState - Get the current state from the "Transfer State" projection

Add this to the demo applications (bank account) and document the process

This is to be done by durable function orchestration as per issue #61