Packaging Apex Enterprise Patterns (AEP) Into Salesforce DX


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.


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


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


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


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 Stack Exchange Survey Results


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.


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!

Salesforce Certification Guide: Development Lifecycle & Deployment Designer


If you have ever attempted to get a Salesforce certification, you may find it stressful knowing how to best prepare for such a task. I attended Salesforce University 2017 and managed to get 2 certification within my 3 attempts. As a historically horrible test take this was a proud accomplishment for myself. As a self-taught developer, currently positioned as a Technical Architect, with ambitions to obtain the highly coveted Salesforce CTA title, I will never forgot the many people who gave back to the community to help me grow in this field.

With that said, I thought in a small way I could give back to anyone else with similar ambitions looking to prepare for the Salesforce Development Lifecycle & Deployment Designer Certification. After failing the test on my first attempt I felt mislead, I understood the concepts of everything the exam guide outlined, I can confidently say that I even feel comfortable teaching a class on it. So how could I have failed? Well for one the details on the test are not just conceptual understandings but specific terms and use cases that can’t necessarily be found by scouring Salesforce’s documentation even if you know what you’re looking for (which again the guide will not help you with).

Retrospective Guide

After absorbing my failure, I wrote down everything that I would need to get a more comprehensive understanding about so that I could debunk every tricky question I would encounter during my retake the following morning. This “retrospective guide” that I comprised that night helped my to pass the certification and I’m posting it in in case it can help you as well. This should not be your only source of study but I would definitely consider it your cliffnotes to make sure you know what to study so that you can be prepared. Good Luck!

Development Lifecycle & Deployment Design Guide:

I will put the important terms in headers with a description of what you need to know about it and any related bullet points I came across along the way.


Governance improves agility by ensuring all members of your team are working together to achieve. Three elements of a responsive, adaptable framework for governance are:

1. Circle of Excellence

A center of excellence (CoE) is a group of people who promote collaboration and best practices to ensure great business results. Need to understand the responsibility of this group and what decisions they are responsible for within the organization and throughout a given project

2. Release Management

Learn, educate, plan, communicate, test, go live, iterate. Understand the cycle of a release what challenges may arise. Keep in mind the Change Control Boards role within a release. Understand available tools like change sets and a sandbox to manage changes, and when it is appropriate to use them. Many question around scenarios that you must advise as a Technical Architect what is the best tool or solution to provide to ensure a release is deployed smoothly and on time.

3. Design Standards

When design or architectural questions arise you need to understand how the standards will dictate the direction going forward. Who governs and enforces these standards?

  • Standard naming conventions
  • Consistently using the Description field
  • Bulkified code
  • Standard methods for deprecating classes and fields
  • Consistent data architecture across all projects

The architect or architecture team in your center of excellence defines your company’s design standards


Program Sponsor

Need to know what their role is and what governance they have, meaning what decisions and/or will fall under their jurisdiction.

  • Executive responsibility for success of the project
  • Execution
  • Drives success

Steering Committee

Who makes up this committee? What is their responsibility within an organization and within a given project?

  • “Team of Champions”
  • Related to “Circle of Success”
  • Prioritize request
  • Review feedback
  • Cross-functional
  • Share decision-making: set and monitor the direction in alignment to the objectives
  • Info Resource – requirements gathering
  • Standardized Data – scale beyond 1 department

Change Control Board (CCB)

Who makes up this board? What responsibility do they have within an organization or a given project?

  • Decide whether the project/scope changes are implemented
  • When there is a diversion from the baseline requirements
  • Made up of stakeholders or their representatives
  • Ensure acceptance of project by client
  • Related to “Release Management”


Need to have a strong understanding of the different editions and their expected and appropriate use cases. Be aware of limitations when developing in a given edition with certain requirements or development team size. Also be able to advise a deployment plan against certain requirements including around Salesforce’s release schedule.

  • What edition org should be used for different types of testing?
  • When is the appropriate time to refresh a sandbox within a dev cycle?
  • How should you resolve a regression expected from upcoming Salesforce release?
  • What are the challenges of a large development team? Deployment, sandbox structure, etc.

Aloha Apps

There was one question where this appeared and it was the correct response to the scenario presented, in which the production org is approaching limits but still needs a new feature. Aloha Apps don’t count against your system limits for apps, tabs, and objects—no matter which edition you’re using

Change Sets

Don’t be fooled by the exam guide, this feature appears in more than 5% of the exam. The right answer may only be connected to 5%, but the feature itself appears several times throughout the exam.

You must understand the steps necessary to setup a change set, as well the limitations when attempting to use them

  • Cannot be used with developer orgs or orgs not related to your companies production or sandbox orgs.
  • The target site metadata will be locked during deployment.
  • Users can still read/write records (I found one question VERY confusing/tricky on this topic).


Depending on your experience or bias you may misunderstand some of the questions revolving around methodologies concerning a dev cycle. Keep in mind that both Agile and Waterfall have pros and cons and both can be used a wrong way and a right way. There is one question specifically that attempts to lead you towards agile alone given the time and budget constraints but Salesforce is using that to promote that waterfall too can adhere to those constraints if you use it correctly.

You don’t necessarily need to understand everything about the two approaches other than their main differences


Known for its structure, the ability to take on very large projects with massive requirements and provide documentation and actionable task towards a complete and through release. Praised for its completeness and adherence to governance but criticized for its clunkiness and heavy maintenance.


Known for its speed and efficiency, no project to big or small but thrives in small achievable deliverables. Criticized for its reckless nature of diving into the task without complete documentation of the requirements. It has the potential of providing immediate results with rapid deployment as its focus, but if not done properly it can miss the mark on the expected result for the end user.


RTM (Requirements Traceability Matrix)

Used for tracking project requirements, great for outlining functional test that need to be accounted for during planning and project management. When refactoring code this can be helpful for creating regression test. Be aware of which scenarios this should be used

R.A.C.I. (Responsible, Accountable, Consulted, Informed)

Used to define each team member’s role and assists with reducing confusion on expectations, in turn, increasing project efficiency.

  • Responsible – Who is completing the task.
  • Accountable – Who is making decisions and taking actions on the task(s).
  • Consulted – Who will be communicated with regarding decisions and tasks.
  • Informed – Who will be updated on decisions and actions during the project.


Stress Testing

Gauge performance during abnormal/extreme conditions. Understand that stress testing is not necessary on the platform because Salesforce has already stress tested the platform so it is not necessary for you to

Load Testing

Gauge performance under expected conditions with varying loads. There are times where this is necessary but if so keep the following in mind:

  • Load testing on a sandbox will not provide the same benchmarks as a production environment. Variables include load patterns, database caching queue for @futures
  • In order to load test you must create a “test plan” that you submit to Salesforce for approval
  • TPS = Transactions Per Second. Used as metric for load testing.

Performance Testing

Gauge performance under particular workloads. This includes both stress and load testing collectively. You can test in sandbox to uncover conflicts between request (locking issues) or to test performance of external web services.

Apex Hammer

Mentioned at least a couple times during the test, but never appropriately from what I remember. At least understand that the Apex Hammer is a real thing (made that mistake my first attempt). Salesforce sometimes refers to this as “Hammer time”, and they do this during every release as a means of regression management.

In short, they use your unit test (even without asserts), to test against potential issues from their upcoming release. First they run all your test on its current version, then they run them again using the new version, its not important that the test pass or fail, but that the do not change results from the first or second attempt. If there is a difference in results then you will receive an email notification to update your Apex.

Tip: Even if the multiple choice suggest it, no you can not make arrangements with Salesforce to move the release date back, you will need to prioritize a fix by leveraging a sandbox that has the update.

Continuous Integration (CI) Considerations

You don’t need to use CI, but you need to understand its purpose and some considerations when advising its implementation as a technical architect

  • Uses migration tool
  • For small dev teams the only benefit is automated testing
  • For large dev teams you will benefit from commercial CI and custom builds.
  • Proper CI creates a new environment per a build cycle, this is not possible in Salesforce until the official release of Salesforce DX
  • This is a source control driven flow development workflow


I hope that helps someone out there cramming for their exam; if it does please comment below with any feedback. Also I don’t have everything listed (had over 20-30 tabs opened that night), but below are some of the references I used along the way as well as my original scratch notes. Also, remember to not limit yourself to Salesforce resources alone, some of the depth of the details you may need may be found elsewhere. Good luck!

Original notes