Salesforce DX Packages - simple recipe to remove apex classes dependencies

With the recent release of Salesforce DX and the package development model it got me thinking how to avoid dependencies so I can isolate my packages.

Business case

The major pain point I saw in the past was around "how to split the metadata so separated teams can work in parallel". For instance, a team can be one line of business or a stream in a project or a feature.

In the old monologic development approach (AKA "the happy soup") we used to have these big merge sessions in order to integrate and some times re-write incompatible solutions written in parallel by separated teams (I won't miss those long nights with cold pizza).

Due to several comments of the merge complexity, Salesforce decided to invest in a better way to allow teams to split their work and this is where the new unlocked packages come into place.

However, in order to fully benefit from the advantages of unlocked packages we have to deal with dependencies between packages. Let's keep in mind that the goal is to be able to create and release isolated packages by Team without depending on each other's features. Without that, we would end up having a single big package and the same merge issues seen in monologic release models.

The packaging dependency can be seen from several angles, here I will give a recipe that I normally use to deal and solve the dependency between Apex classes.

Firs at all, what is a dependency?

In object-oriented programming, a dependency is a relationship between the classes in your application (see reference).

Let's Image we have two classes: our controller that calls a service class (AKA a "helper") to execute some business logic.

In this case, LB_DemoControllerDependent class creates an instance of LB_ServiceLogic on line 4. This reference creates a dependency because the class LB_ServiceLogic must exist in order DemoControllerDependent to be compiled.

Let's put it simply if class A needs class B to compile, we can say class A depends on class B.

From a diagram point of view, we can see that dependency as an arrow between the classes.

Figure 1: Dependant Classes

How to solve dependency?

I won't give a long explanation about dependency injection or Inversion of control there is plenty documentation out there that you can read if you are interested about the topic (a helpful reading topic for those nights where you have issues falling sleep ;-) ).

Here I will focus on proving a "simple recipe to remove apex classes dependencies".

The goal: remove that line (dependency) that we saw in figure 1 between our controller and the specific service logic.
The reason: we want to place our controller on a separated unlocked packaged so it can be deployed without having our service class in the same package or already present in the Salesforce Org.

Create an Interface class. An interface is a contract between two classes. This way your controller doesn't need to know the exact class with the business logic, it just needs to know the "contract" that the service class will follow.

Create a custom metadata type: The custom metadata allow us to specify (or Inject) the name of the real class we wont to use on real-time. Here I will use a simple metadata structure (just a simple text field).

However, you can have a more sophisticated logic where you, for example, you can specify the order or execution to have a flag to activate and deactivate entries.

metadata image.

Update your controller class: Update your service class so your class becomes "Independent". To do so your controller class will now leverage the Interface created on step 1 and the custom metadata created on step 2 in order to indirectly call the service class.

Please also note that we are using a for loop, this will allow the controller to call than more one service class if required.

Update your service class: Similarly, your service class should implement the interface, that way your teams can work independently of the caller class.