Why Architecture Matters at Scale

Module 42's banking system put trigger logic directly in TransactionTrigger and TransactionValidation, and query logic directly inline in BankAccountService. For a nine-lesson project, this was the right amount of structure — anything more would have been premature. But imagine that same codebase with forty objects, two hundred fields, and a dozen developers touching it simultaneously: the same "logic lives wherever it's needed" approach breaks down fast.

• Duplicate logic — the same query written slightly differently in five different triggers, each with its own subtle bug.
• Hard-to-test code — business logic tangled together with SOQL and DML, forcing every unit test to hit the database even for logic that has nothing to do with data access.
• Merge conflicts — many developers editing the same giant trigger file simultaneously.
• Fear of change — nobody fully understands how a change in one place will ripple elsewhere, so people are afraid to refactor even obviously bad code.

The remaining lessons build up one cohesive layered architecture, piece by piece: separation of concerns (Lesson 2) as the guiding principle, then concrete layers — service (Lesson 3), selector (Lesson 4), domain/trigger handler (Lesson 5) — followed by supporting patterns — dependency injection (Lesson 6), factory (Lesson 7), strategy (Lesson 8) — and closing with DTOs and a caution against overengineering (Lesson 9), so the module ends by reinforcing that architecture is a tool, not a goal in itself.