Use Sub-Packages to Aggregate Related Concepts

It is a good practice to put all related concepts in a sub-package.

For example, in a claim model BOM there can be classes, primitive types, and enumerations relating to customers, policies, and claims. So three sub-packages can be created to collect the different types together in different groups. If the root package name is com.example.claimmodel, then there can be sub-packages called:

com.example.claimmodel.customer
com.example.claimmodel.policy
com.example.claimmodel.claim

Organizing classes, enumerations, and primitive types in sub-packages makes them easier to find when viewing the BOM, and also when scripting it means that the factory has fewer methods in it, which makes it easier to find the method that you need.

As an extension to this, you can actually have sub-packages in different BOM files. When doing this, it is important that each package or sub-package is only in one BOM file. Using the above example, you can have three BOM files for the three sub-packages, or you can have four if some things are defined in the root package. Alternatively, it can just be split into two BOM files with the root package and two sub-packages in one BOM file, and the third sub-package in the second file.