Module Structure

At the lowest level, there is a separate TMForum extension module for each Broadleaf microservice that needs additional functionality to support a TMF goal. For example, there is a separate broadleaf-tmforum-pricing-services module for PricingServices, as well as a broadleaf-tmforum-catalog-services module for CatalogServices. These modules unlock additional TMForum-specific capabilities on top of core Broadleaf concepts.

The scope of impact within this tier of module is bounded to a particular microservice.

There is a broadleaf-tmforum-core 'core' extension library that each of the service-specific extension modules rely on.

There are a lot of concepts that are standardized across all TMForum APIs in the design guidelines. For example, the patterns for pagination, sorting, attribute filtration, and attribute selection are shared between all the APIs.

Naturally, it makes sense to consolidate this shared functionality in one place, so the 'core' module is where those concerns live. Often, the core module will define a common interface and an abstract implementation of a component that each service-module can implement with type-specific behavior.

In the interest of making the extensions easy to consume, there is a broadleaf-tmforum-starter-base module which itself includes each of the service-specific extension modules. This allows clients to simply specify a single dependency that automatically enables the appropriate functionality, as documented here.