Architecture

Packaging Apex Enterprise Patterns (AEP) Into Salesforce DX

Standard

Recently I wrote about “Architecture Enterprise Patterns (AEP) and Salesforce DX” and how I believe they are going to dramatically change the landscape for Salesforce developers everywhere. Today I wanted to briefly outline my progress with this reality. As part of the Salesforce DX Pilot this year, I got a first hand look at what the future holds when it comes to managing your Salesforce orgs. In addition to that, this year, as we expand to a global footprint, I’ve made it my personal mission to prepare my company for enterprise level development. Thankfully with the help of contributors like Martin Fowler and Andrew Fawcett, I believe I’m off to a great start.

Prerequisites

I will make this guide as simple to follow along as possible, but it should be noted that in order to fully grasp the benefits of this package and its practices you should at least familiarize yourself with the following

Also, for the purposes of this tutorial I will assume that you are already using DX or familiar with it and simply guide your through my steps for an ideal packaging of AEP within the DX structure.

NOTE: I will continue to update this article as more of my perspective on DX and the AEP evolve.

Getting Started

You should already have the SFDX CLI installed and setup, as well authorized your Hub Org.

1. Create a DX workspace

Traditional Salesforce workspaces might include .config and .deploy meta folders as well as the src directory that houses /classes, /triggers, /etc. but a DX workspace is likely to follow the following structure.

<project root> / <package name> / <module name> / <your source in whatever directory structure you want>

Which could look something like this:

  • MyProject/main/default/classes
  • MyProject/main/test/classes
  • MyProject/main/test/classes

Now as DX becomes official this should become more clear, but either way the aim is to allow for more flexibility to decouple your APEX and meta data based on projects, packages, and modules. All that to say that we are going to setup a DX workspace just for our AEP project so that it can be managed in its own repository. To begin, run this from the directory you wish to store your workspace:

sfdx force:workspace:create -n apex-enterprise-patterns

This will create a /apex-enterprise-patterns directory with the default /force-app folder already setup. Once that’s created be sure to change directories into your new workspace:

cd apex-enterprise-patterns

2. Clone AEP packages to your workspace

We are going to now clone what I will refer to as the traditional or metadata api (mdapi) versions of the ApexMocks and ApexCommons (aka fflib) to our workspace (I’ve chosen to maintain this within the workspace so that I can more easily track future contributions to these public projects). We will begin with ApexMocks since it is a dependency of ApexCommons:

git clone [email protected]:financialforcedev/fflib-apex-mocks.git Packages/fflib-apex-mocks

Followed by:

git clone [email protected]:financialforcedev/fflib-apex-common.git Packages/fflib-apex-common

*NOTE: I deployed these to a /Packages directory so that I can more clearly indicate its purpose in the workspace

3. Convert MDAPI to Source

Next we need to convert the traditional mdapi structure to the new DX structure.

sfdx force:mdapi:convert -r Packages/fflib-apex-mocks/src -d force-app/apex-mocks

and

sfdx force:mdapi:convert -r Packages/fflib-apex-common/fflib/src -d force-app/apex-commons

*NOTE: Unfortunately at the time of this writing this conversion will create the following structure to include /main but in the future it may be possible to remove this unnecessary folder.

(Optional) As a preference I’m going to remove the /main directory and move the files respectively with the following:

mv force-app/main/default

Conclusion

In the future I may update this post with more details but rather than delay publishing my current progress I’m going to conclude my findings here for the moment. This should demonstrate some of the key differences between working with traditional mdapi and the new DX layout. With that said, keep in mind that only components within the DX model can be deployed through the force:push command. In addition, mastering the abilities of this new command interface does not have to be a daunting task of your development team, rather the aim should be to use these new abilities to script automated deployments and interactions.

Hopefully this brief example can still add some benefit to your adoption of Salesforce DX. If there is anything specific that you would like to see addressed still feel free to comment below and I will look to update the article accordingly in time. Thanks for reading!

Architecture Enterprise Patterns (AEP) and Salesforce DX

Standard

At this point many have heard about the rave behind Salesforce DX and the hope it brings. As DX begins to rollout in the following year, this is going to create an architecture paradigm shift in the entire Salesforce developer community in a very good way. In the past, Saleforce has been a foe to many developers, with its multi-tenant constraints, steep learning curve and uncooperative metadata structure, it has ranked as on of the most dreaded platform to develop on by the Stack Exchange Developer Survey in back to back years.

2016

2016 Stack Exchange Survey Results

2017

2017 Stack Exchange Survey Results

Salesforce Architecture for the Win!

DX is definitely a difference maker, but it alone is not the solution to better Salesforce development experience. One major aspect that is neglected in all programming, but can be detrimental to working with the Salesforce platform, is the lack of architecture.

As Martin Fowler put it, “Architecture is the sensibility behind the code” or in other words, “stuff that’s hard to change.” Too often we create our own obstacles writing software that we can’t manage as the project evolves, and likewise can’t be supported by others who all to quickly will refer to it as legacy code. But good architecture is a game changer, it is the difference maker.

We happen to be in a time where the stars are aligning and two opposing forces are working as one. The Salesforce organization is creating an overall better development cycle for devs, and the Salesforce community is embracing a more serious conversation about good architecture. On one end you wait expectantly on the GA release of DX, and on the other side you see the emerging conversation of Apex Enterprise Patterns (AEP). DX allows for Separation of Concerns (SOC) with the integration and deployment cycles, while AEP structures the SOC of your org or app’s codebase.

Conclusion

Based on these two developments, I’ve already begun to restructure our monolithic Salesforce org to a more modular structure; using AEP as a foundation while building separate projects, apps and features within their own separate repositories, capable of being provisioned together again. Check out “Packaging Apex Enterprise Patterns Into Salesforce DX” (coming soon) for a first-hand walk through of my initial experience bringing these two together.

Would love to hear any thoughts or feedback you have about this perspective on the future of Salesforce development. Thanks for reading!