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

2017

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!