
This one maps fintech domain constraints directly to Rust design decisions. It's built around the core truth that you can't use f64 for money, ever, and shows you how immutability, precision, and audit trails flow down from regulatory requirements into concrete patterns like rust_decimal newtypes and Arc for transaction records. The trace-down tables connect "need immutable transaction records" to specific ownership choices and crate selections. Most valuable when you're starting a payment system or trading platform and need to see why certain architectural choices aren't optional in finance. The currency type example and common mistakes section will save you from the classic blunders.
$ npx -y skills add actionbook/rust-skills --skill domain-fintech --agent claude-codeInstalls into .claude/skills of the current project.
Layer 3: Domain Constraints
| Domain Rule | Design Constraint | Rust Implication |
|---|---|---|
| Audit trail | Immutable records | Arc, no mutation |
| Precision | No floating point | rust_decimal |
| Consistency | Transaction boundaries | Clear ownership |
| Compliance | Complete logging | Structured tracing |
| Reproducibility | Deterministic execution | No race conditions |
RULE: Never use f64 for money
WHY: Floating point loses precision
RUST: Use rust_decimal::Decimal
RULE: All transactions must be immutable and traceable
WHY: Regulatory compliance, dispute resolution
RUST: Arc<T> for sharing, event sourcing pattern
RULE: Money can't disappear or appear
WHY: Double-entry accounting principles
RUST: Transaction types with validated totals
From constraints to design (Layer 2):
"Need immutable transaction records"
↓ m09-domain: Model as Value Objects
↓ m01-ownership: Use Arc for shared immutable data
Sponsors