Everything, In One Place
This one is the full compilation: absolutely everything you need to know about separation of concerns, the Apex Common Library, and the Apex Mocks library, in a single sitting.
Fair warning, it’s about seven and a half hours. So while the video runs start to finish, this post is your map. Each section below links to the individual write-up for that topic, so you can dip in wherever you need rather than scrubbing through a very long video.
If you’re starting from scratch, work through in order. If you’re here for one specific thing, jump straight to it.
Why Bother With Any Of This?
The short version: if you write code in your org at all, you should be using separation of concerns.
Separation of concerns means putting logical boundaries on your code. Those boundaries make it easier to understand, easier to maintain, and much more flexible when it needs changing. And every codebase that has ever existed needs changing, constantly.
The Apex Common Library is a battle-tested implementation of those boundaries for Salesforce, originally from FinancialForce. Rather than inventing your own architecture, you get one that thousands of orgs already run on, that new developers may already know, and that you didn’t have to design yourself.
This pairs closely with my SOLID Design Principles series. SOLID tells you how to design individual classes; separation of concerns tells you how to organise them into layers.
Part 1: Foundations
1. Introduction to the Separation of Concerns Design Principle
What it is, why it matters, and a deliberately simplified example before we get into the frameworks.
2. Introduction to the Apex Common Library
What the library gives you and how the pieces fit together.
The Factory And Unit Of Work
3. The Factory Method Pattern
The pattern that makes everything else swappable, and therefore testable.
4. The fflib_Application Class
The library’s implementation of that factory, and the thing you register your classes with.
5. The Unit of Work Pattern
How to batch up all your DML and commit it once, safely, in the right order.
6. The fflib_SObjectUnitOfWork Class
The concrete implementation, including how it handles relationships between records you haven’t inserted yet.
The Three Layers
This is the heart of it. Three layers, each with a clearly defined job.
7. The Service Layer
Where your non-object-specific business logic lives.
8. Implementing the Service Layer
9. The Template Method Pattern
The pattern the Domain layer is built on. Also, incidentally, exactly how a trigger framework works.
10. The Domain Layer
Object-specific logic. Everything that’s true about an Account, in one place.
11. Implementing the Domain Layer
12. The Builder Pattern
13. The Selector Layer
All your SOQL, in one place per object. No more hunting for which of forty classes queries Account.
14. Implementing the Selector Layer
Testing, Which Is The Actual Payoff
15. The Difference Between Unit Tests and Integration Tests
Most “unit tests” in Salesforce aren’t. Here’s why that matters.
16. Unit Test Mocks with Separation of Concerns
17. Implementing Unit Tests with the Apex Mocks Library
Tests that run in milliseconds because they never touch the database.
This is where all the earlier work pays off. Once your layers are separated and your factory can hand out mocks, you can test business logic without inserting a single record. That’s the whole reason to do any of this, and it’s directly the Dependency Inversion Principle in action.
Is It Worth It? Honestly.
There’s real overhead here. More classes, more ceremony, a genuine learning curve for anyone joining your team, and a small change touches more files than it would otherwise.
For a small org with a handful of Apex classes, this is probably overkill. I’d rather say that plainly than pretend otherwise.
For anything substantial, it pays for itself. Particularly if you’ve got multiple developers, a codebase that’ll live for years, or complex business logic that genuinely needs testing properly.
The honest middle ground: you don’t have to adopt all of it at once. The Selector layer alone, just consolidating your SOQL per object, delivers real value on day one and costs you almost nothing. Start there, see how it feels, and add layers as you need them.
All the code and a full written wiki are up on GitHub, and the library itself lives in the Apex Enterprise Patterns repo.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
