What is the Apex Common Library?
The Apex Common Library is an open source library originally created by Andy Fawcett when he was the CTO of FinancialForce and is currently upkept by Andy Fawcett, John Daniel, John Storey, Dave Esposito, and Matt Gerry. Aside from its origins and the fflib_ in the class names, it is no longer linked to FinancialForce in any way.
The library was originally created because implementing the Separation of Concerns Design Principle is difficult no matter what tech stack you're working in. For Salesforce, the Apex Common Library was built to simplify the process of implementing Separation of Concerns as well as assist in managing DML transactions, creating high quality unit tests (you need the Apex Mocks library to assist with this) and enforcing development and security best practices. The Apex Common Library helps your teams generate clean, understandable and flexible codebases that are simpler to maintain.
Does The Apex Common Library Implement Separation of Concerns for me Automatically?
Unfortunately, it's not that simple. This library doesn't just automatically do this for you, no library could, but what it does is give you the tools to easily implement this design principle in your respective Salesforce Org or Managed Package. Though there are many more classes in the Apex Common Library, there are four major classes to familiarize yourself with to be able to implement this, four object-oriented programming concepts and four major design patterns. Additionally, it's beneficial if you understand the difference between a Unit Test and an Integration Test. We'll go over all of these things below.
If the list below reads as intimidating from where your org currently stands - four classes, four patterns, a testing philosophy - know that the layers are independently adoptable. A service layer that uses no unit of work, no domain and no selector classes is still a huge step forward, and you can grow into the rest incrementally. There's a recommended adoption order for existing codebases in chapter 16.
The Four Major Classes
- fflib_Application.cls - This Application class acts as a way to easily implement the Factory pattern for building the different layers when running your respective applications within your org (or managed package). An "Application" for an org based implementation could mean a lot of things, but think of it as a grouping of code that represents a specific section of your org. Maybe you have a service desk in your org, that service desk could be represented as an "Application". This class and the factory pattern are also what make the Apex Mocks Library work; without implementing it, Apex Mocks will not work.
- fflib_SObjectDomain.cls - This houses the base class that all Domain classes you create will extend. The many methods within this class serve to make your life considerably easier when building your domain classes out (you will typically create a domain for each object that requires a trigger). For more information, check out the Apex Common Domain Layer Implementation Guide for more details.
- fflib_SObjectSelector.cls - This houses the base class that all Selector classes you create will extend. The many methods within this class will serve to make things simpler when implementing a selector class for the various objects in your org. For more information, check out the Apex Common Selector Layer Implementation Guide.
- fflib_SObjectUnitOfWork.cls - This houses the logic to implement the Unit of Work design pattern in your code. There are a ton of useful methods within it that will make your life developing on the platform quite a bit simpler. For more information on the fflib_SObjectUnitOfWork class and the concept itself, please refer to the guide on how to use the Unit of Work Pattern in Salesforce.
Honorable mentions beyond the big four: fflib_QueryFactory (the fluent query builder underpinning the selector layer, covered in chapter 14) and fflib_SecurityUtils (one-call CRUD and field-level security checks, covered in chapter 6). And the Apex Common Library has a sibling in the same GitHub organization worth knowing about: force-di, a dependency injection framework this guide covers in its final part.
The Four Object Oriented Programming Concepts
- Inheritance - When a class inherits (or extends) another class and the sub class gets access to all of its publicly accessible methods and variables.
- Polymorphism - When a class uses overloaded methods or overrides an inherited class's methods.
- Encapsulation - Only publishing (or making public) methods and class variables that are needed for other classes to use it.
- Interfaces - An interface is a contract between it and a class that implements it to make sure the class has specific method signatures implemented.
More information on the difference between Inheritance and Polymorphism
The Four Design Patterns
- The Factory Design Pattern - Used in the fflib_Application class
- The Unit of Work Design Pattern - Used in the fflib_SObjectUnitOfWork class
- The Template Method Design Pattern - Used in the fflib_SObjectDomain class
- The Builder Pattern - Used in the fflib_QueryFactory class which is heavily leveraged by the fflib_SObjectSelector class