How do you organize your org metadata? - unmanaged packages, custom folder structure in SFDX....?

Question

I've been considering ways to organize my company's SF metadata, with the goal of grouping together metadata that are specific to particular processes, while leaving out shared metadata.

SF has made some movement towards using Unmanaged Packages with SFDX for 'package driven development'. I've typically viewed this as out of my domain, something for app devs seeking to share their work outside of their org, but now I've been wondering if there's value in using unamanaged packages internally.

For example, our main business in Salesforce can be divided up into three separate sets of processes for our three areas of business.

At a high level, I could potentially group the unique metadata for each area into its own unmanaged package, leaving any shared metadata out.

However, as an alternative, I could also use SFDX's allowance for custom folder structure, to simply divide our metadata repository into multiple parent level folders. For example, a 'Program A' folder with its own \force-app\main\default\ structure, a sibling 'Program B' folder with its own, and a 'Shared' folder that holds the shared metadata.

I could also see a hybrid of these two systems, where the folder structure holds the highest categorization of metadata (major business areas/programs), while unmanaged packages group specific processes or tools within those areas. I think this would better reflect the intent of packages.

Does anyone use this method, or other methods to organize and group metadata directly, rather than relying solely on documentation and digging through code to figure out what components are related to a given process or area of business?

Answer 1

This question is rathet opinion based, which doesn't really align with this community. That said here's my opinion.

I strongly recommend having all metadata (including shared metadata) in git for inclusion in unlocked package(s).

How many you have really comes down to how you might like to version the metadata and perform any testing.

By putting it all in one package you simplify dependency management but guarantee that you will always upgrade everything when installing (obliterating any locally made changes to the packaged metadata).

Putting it is separate unlocked packages you must manage dependencies explicitly, though I would argue this is a good thing. When building features this will make you think about the bigger picture and how the feature will fit with the existing solution. It also means that an upgrade for one package need not actually impact any of the metadata for the other packages.

If you have a very large and complex solution, I would certainly consider a hybrid of multiple unlocked packages and "module" folders within each.

The "module" is fundamentally only conceptual in how it works since there is nothing stopping you have cyclic dependencies between them. On the other hand, packages cannot have cyclic dependencies. You have to have a tree of packages, not a graph.