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
- Custom Objects
- Custom Fields
- Layouts
- Object Permissions
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
- Custom Metadata
- Custom Labels
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
CSS has an independent scope from Objects and Configurations, but will probably be changed often.
4. Package Implementation as Dependent
- Lightning Web Component
- Apex
- Flows
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.
