Advanced 25 min read

Separation of Concerns

By the end of this lesson, you'll be able to:

Define separation of concerns as an architectural principle
Identify the distinct concerns tangled together in a typical trigger
Recognize this as the guiding principle behind every layer in this module

Prerequisites: "Why Architecture Matters at Scale"

One trigger, several tangled concerns

Look back at Module 42's TransactionValidation trigger: it queries accounts (a data-access concern), checks account status (a business-rule concern), and calls addError() (a trigger-specific concern). All three are legitimate pieces of logic, but bundling them into one file means a change to how accounts are queried risks accidentally touching the business rule right next to it.

Untangling the concerns

Data access:      "how do I get Bank_Account__c records?"
Business rule:     "is this account allowed to accept a withdrawal of this size?"
Trigger mechanics: "which records does Trigger.new contain, and how do I reject one?"

Separation of concerns means each of these three questions gets answered in exactly one place: a selector (Lesson 4) answers the first, a service (Lesson 3) answers the second, and the trigger handler (Lesson 5) answers the third — each independently testable, independently changeable.

Why this is a principle, not a specific pattern

Separation of concerns doesn't mandate any particular class names or folder structure — it's the underlying reason the specific layers in Lessons 3-5 exist at all. Understanding the principle means a team could name their layers differently and still be following the same idea; the remaining lessons just give one well-established, widely-recognized set of names for it.

Exercise

As a comment, identify the three distinct concerns bundled together in Module 42's TransactionValidation trigger, using the same three-question framing from this lesson.

Show hint

Data access, business rule, trigger mechanics.

APEX

Separation of Concerns Quiz

1. What does separation of concerns mean as a principle?

Each piece of code has exactly one job, so a change to one concern does not risk breaking an unrelated one Every class must be under 10 lines of code All logic should live in a single trigger for simplicity It is a specific Salesforce feature, not a general principle

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

Separation of concerns means each piece of code has exactly one job — a trigger fires and delegates, a service holds business logic, a selector holds queries — so a change to one concern doesn't risk breaking an unrelated one.

← Why Architecture Matters at Scale Service Layer →