Salesforce: Separating a Service Into Unlocked Packages

Unlocked packages allows us to think in terms of services. We can release a stand-alone service apart from others. But even an individual system can be broken up to resemble the intrinsic separations of an individual service.

1. Package Objects as a Dependency

Data is at the core of Salesforce; everything it built around the data. The only metadata data depends on is usually other data. This means that data can be separated and managed independently from all else. Data is usually designed around the domain anyway, not the implementation. Separating objects into a package scope encourages the focus on the domain.

2. Package Implementation Configurations as a Dependency

In applications and services, configurations have always be independent. Sometimes they are represented by one or more text files. Sometimes they are depicted as environment variables. In every case configurations are separated, stand-alone, and releasable independently from the rest of the system.

Spinning configurations into a package allows for a clean unimpeded release of configuration changes.

3. Package Styles as a Dependency

CSS has an independent scope from Objects and Configurations, but will probably be changed often.

4. Package Implementation as Dependent

This now frees the implementation from the rest of system. It also enables services with similar dependencies but different scopes to be decoupled, because now they can be.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store