Un système bancaire en UML

Nearly every banking example on the internet gives Account a balance attribute and a pair of methods that add to it and subtract from it. It is the first thing to delete, because no ledger that has to be auditable works that way.

A stored balance is a second copy of a fact the postings already contain. Two copies of a fact can disagree, and when they do - a partial failure, a retried message, a migration - there is no way to tell which is right, because the balance carries no history to check it against. Deriving it, as balance() on the figure above, makes disagreement impossible by construction.

The composition on the right of the hero figure is the second load-bearing decision. A Transaction is composed of exactly two Postings - the multiplicity says 2, not 0..* - and by convention they sum to zero: money leaves one account and arrives at another.

Drawing an association from Account straight to Account, which is the obvious first attempt, loses both halves of that. It loses atomicity, because two arrows can exist independently and a transfer cannot half-happen. And it loses the reference: a transaction is a thing customers ask about by number, dispute, and reverse, which means it is an entity and not a line between two others.

The filled diamond then says the postings die with the transaction. That is correct and it is also a constraint on the code: you cannot delete half a transfer, and a reversal is a new transaction rather than an edit to the old one. The class diagram guide has the full rules for when a diamond is filled.

A state machine earns its place whenever an object has a lifecycle that rules depend on, and money moving is the archetype. The value is not the four boxes, which anybody could guess - it is the transitions that are absent.

Settled has no outgoing transition. That says a settled transfer is final, and a reversal is a different transaction rather than a state change, which is the same claim the composition on the domain model made. Rejected has none either: an approval after a rejection starts a new transfer. Guards make the rest explicit - reject [limit]names why, and a diagram that says only "reject" leaves the reason to the reader.

For the same treatment of a different domain, see e-commerce architecture, modelled. For the data-modelling half of a ledger - keys, cardinality and the schema underneath - see ER diagrams.