Having a good foundation and structure to your Salesforce Apex code base is key for a successful implementation. It allows us to scale our application in a predictable manner.

Without any structure or framework we’re often faced with the same problems to solve over and over again, and it’s difficult to share the knowledge to other developers what they should and shouldn’t do in the code base.

It’s much easier to have a framework in place to assist with providing structure and avoiding the common development issues on Salesforce. This is where FFLIB comes in. A framework provided by Financialforce.

In this post I’m going to introduce you to FFLIB and explain why I believe it’s a great framework to base your applications on. In the upcoming posts I’ll be covering more in depth topics such as installing the tools to how to use them in your applications.

Introducing FFLIB Apex Common & Apex Mocks

FFLIB Apex Common is a framework provided by Financialforce and is completely open source. It’s also based around the enterprise design patterns recommended to be followed by Salesforce. I’ll introduce Apex Mocks shortly.

Apex Common

It encompasses the following aspects of the enterprise design patterns within the framework:

  • Domain layer
  • Selector layer
  • Service layer
  • Unit of work

These layers allows us to build our application in a predictable way which is scalable and highly testable.

Domain layer

The domain layer is where in your application you’ll only be working and modifying sObjects (a domain). It’s purpose is to help centralise working with sObjects to reduce duplication and to encourage reuse across your application.

It’s also where triggers will reroute to when records are created, edited or deleted. The layer provides a simple way to manage records throughout the execution of a trigger and further encourages reuse of domain logic when not inside a trigger context.

Some of the nice things about the domain layer are:

  • Centralises code responsible for working or modifying with sObjects.
  • Follows the best practice of having one trigger handler per sObject.
  • Easy to follow and understand flow through the trigger lifecycle.
  • Encourages code reuse of domain logic to other areas of the application.

It took me a while to understand, but your business logic doesn’t necessarily have to live in this layer, typically it’s held in the service layer. The domain layer is there for working or modifying sObjects, such as requesting to mark all opportunities as closed won.

Selector layer

An extremely useful layer in FFLIB is the concept of the selector layer. The idea is that all of your queries across your complete application will be held in selector classes specific for an sObject. For example, you’ll have a selector class for the accounts object and another for the opprtunities object.

The benefit of this approach is that you’re certain no matter in your application you can be sure that all of the required fields are selected to avoid the typical exception stating you’ve not selected the field you’re attempting to use.

Service layer

This is the layer within your application where most of your business logic will be placed. It’s a which should be calling the other layers.

Apex Mocks

This is one of my favouritist Salesforce repository out there! It’s a unit testing framework which is based on Mocketo written in Apex.

Achieving the 75% code coverage requirement on Salesforce is pretty easy on small projects, but when moving to medium to large scale projects it can be difficult to maintain and improve upon. One of the major challenges is having to set up so much test data in order to test a simple scenario due to interconnected dependencies within our applications.

The result is that either unit tests are slow to execute and or there aren’t true unit tests as such, but unit tests which simply generate the required code coverage. Of course this outcome isn’t intended, it’s just a typical fallout of not having an easy unit testing framework available or an application structure which supports it.

Get started

The first step to getting started is getting both frameworks installed. You can install them both from Github at: