Reference Architecture

Broadleaf Microservices are delivered as independent Spring Boot applications. Broadleaf services can be deployed in a composed fashion or each service can be deployed in its own container offering maximum Deployment Flexibility

The following diagram is explained in more detail just below. For a full list of services, see the services section.

This diagram shows a logical depiction of how Broadleaf services typically interact with applications.

The diagram shows two types of applications. The upper left is representative of custom applications. This might be a company website, mobile application, POS, ERP, or other systems that need to interact with Broadleaf. The lower right represents the Broadleaf admin which is a rich interface for managing the data for Broadleaf microservices.

Between the applications and the services, Broadleaf recommends that you utilize an API Gateway to facilitate things like routing and CORS enablement across the different services.

The applications will consult with an authorization server to access tokens that will allow access to the service apis.

It is helpful to think of Broadleaf Services as one of three types.

Resource Tier Services are the most common. They represent bounded contexts for common commerce concepts. Each resource tier service utilizes a data store to persist. With the Broadleaf provided services, resource tier services are not allowed to communicate with other Resource Tier services directly and instead must use a messaging channel like Kafka or other Spring Cloud Stream compatible provider.

Composite Services represent services that need to aggregate information or processing. For example, Cart Operations needs to coordinate with Cart, Pricing, Offers, etc. in order to facilitate the checkout process. Note that, composite services do not have a persistence layer.

Admin Supporting Services are used by the unified React based admin.

Utility Services include authorization where security tokens are issued and config service which allows for management of runtime properties by environment.

Commerce implementation will also interact with 3rd parties like tax providers, payment gateways, ERP systems. These will most often occur through configuration for supported integrations or extension for your own providers or systems.

Within the Broadleaf commerce deployment, there will also be other infrastructure components such as ZooKeeper and Solr for highly scalable search, Kafka (or other Spring Cloud Stream compatible binder) for intraservice communication, and databases (PostgreSQL, MariaDB, MySQL, Oracle) for persistence.