A bank account model represents account information, including balances and other data consumers need to understand or operate the account. Its design balances simplicity, usefulness, and domain accuracy. section 8.4.1 section 8.7.1
Choose balance detail according to user needs. A single common balance helps non-experts, while multiple balances support advanced use cases. Add currency and identify a default balance so consumers do not guess. section 8.4.1 section 8.4.2
Shape the model around relevance and consumer effort:
- Retain properties that support account needs, such as IBAN, number, type, name, and safe to spend; remove distracting data such as an unnecessary creation date. section 8.7.1
- Provide processed values when consumers would otherwise reproduce business rules; safe to spend can combine balance, overdraft availability, and known transactions. section 8.4.3
- Keep a small current-balances array when useful, but represent large transaction histories separately with operations supporting filtering and pagination. section 8.7.2
- Reuse suitable organizational or industry patterns, including ISO 20022, without allowing standardization or complexity to override user requirements. section 8.9.1
Representing multiple balances
A model can expose a balances array containing objects with type values such as "value-date" and "expected". Each object carries its balance data, while a Boolean default flag identifies the most commonly used balance. section 8.6.2
Figure 8.15 Different properties representing the same type of data may be grouped into an array.
Use the figure to see how repeated balance properties become a typed balances array. section 8.6.2
Figure 8.16 Each piece of data must be relevant.
Use the figure to inspect how each property earns its place through relevance to account needs. section 8.7.1
Figure 8.17 We shouldn’t embed lists requiring filtering or pagination.
Use the figure to distinguish small embedded lists from large collections that need separate operations. section 8.7.2
