Design the Account Model
By the end of this lesson, you'll be able to:
- Design a data model for a simplified banking system
- Decide which fields belong on the account versus a separate transaction object
- Recognize why a running balance field needs careful design
Prerequisites: Module 41: "Professional Engineering Practices II"
Two objects, one relationship
Bank_Account__c
Name (Text)
Account_Number__c (Text, unique)
Balance__c (Currency)
Status__c (Picklist: Active, Frozen, Closed)
Transaction__c
Bank_Account__c (Lookup to Bank_Account__c)
Type__c (Picklist: Deposit, Withdrawal)
Amount__c (Currency)
Transaction_Date__c (DateTime)This mirrors Module 26's Opportunity-to-Account rollup pattern structurally — a parent record (Bank_Account__c) whose summary field (Balance__c) is derived from its children (Transaction__c) — but here, an incorrect rollup isn't just a reporting inconvenience, it's actual money being wrong.
Why Balance__c is stored, not calculated live
A live SUM(Transaction__c.Amount__c) query on every balance check would be correct but slow, and re-running it constantly wastes SOQL (Module 20). Instead, Balance__c is a stored, incrementally-updated field — Lesson 2's trigger updates it directly each time a transaction is created, the same pattern as Module 26's rollup trigger, applied here with money instead of a report metric.
Why Status__c matters for a financial system specifically
A Frozen or Closed account should reject new transactions entirely — this project's later lessons (validation, security) will enforce this. Designing the status picklist now, even before the enforcement logic exists, is the same "design before code" discipline from Module 41's technical-design-document lesson: deciding upfront which states are valid makes the enforcement code that comes later straightforward rather than an afterthought bolted on.
Exercise
As a comment, explain why storing Balance__c as an incrementally-updated field is preferable to calculating it live from Transaction__c on every read, for a banking system specifically.
Show hint
Think about how often a balance might be checked versus how often it changes.
Design the Account Model Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
This project builds a simplified banking system: Bank Accounts that hold a balance, and Transactions that record every deposit and withdrawal affecting that balance — the same requirement-and-data-model discipline from every earlier project module, now applied to a domain where correctness genuinely matters.