💸 Personal Finance Tracker with Event Sourcing

A personal finance app built on an event-sourced ledger — as much a learning exercise in CQRS and event sourcing patterns as it is a useful tool.

Every personal finance app I've tried stores current balances and transactions as mutable rows in a database. That means if an import goes wrong, a category changes, or a new rule needs to be applied retroactively, you're in trouble. Event sourcing flips the model: the ledger is a sequence of immutable facts — TransactionImported, CategoryAssigned, RuleApplied — and the current balance is always a projection computed from that log.

The appeal of building this as a personal project is that the domain is constrained and well-understood, which makes it ideal for exploring event sourcing and CQRS patterns without domain uncertainty getting in the way. The write side would accept commands (ImportTransactions, AssignCategory, CreateBudget), validate them, and append events to the store. Multiple read-side projections would compute different views from the same event log: a running balance, a category breakdown, a monthly trend report.

One specific thing I want to explore is retroactive rule application. If I define a new rule — "all transactions from Merchant X are category Y" — I want to replay the event log with that rule applied and see my historical categorization update. This is trivial with event sourcing and nearly impossible with a mutable database model. The same pattern applies to fixing import errors: append a correction event rather than mutating historical data.

Beyond the finance application itself, I want to document the architectural choices, the tradeoffs of event sourcing at small scale, and the places where the complexity isn't worth it. That documentation would be the real deliverable — a grounded case study in when and how to apply these patterns.