Identifying micro-frontend boundaries

To improve team autonomy, the business capabilities provided by an application can be decomposed into several micro-frontends with minimal dependencies on each other.

Following the DDD methodology discussed previously, teams can break down an application domain into business subdomains and bounded contexts. Autonomous teams can then own the functionality of their bounded contexts and deliver those contexts as micro-frontends. For more information about separation of concerns, see the Serverless Land diagram.

A well-defined bounded context should minimize functional overlap and the need for runtime communication across contexts. The required communication can be implemented with event-driven methods. This is no different from event-driven architecture for microservices development.

A well-architected application should also support the delivery of future extensions by new teams to provide a consistent experience for customers.

How to slice a monolithic application into micro-frontends

The Overview section included an example of identifying independent functional contexts on a web page. Several patterns for splitting the functionality on the user interface emerge.

For example, when the business domains form stages of a user journey, a vertical split on the frontend can be applied, where a collection of views in the user journey is delivered as micro-frontends. The following diagram shows a vertical split, where Catalog, Checkout, and Invoice steps are delivered by separate teams as separate micro-frontends.

For some applications, vertical split alone might not be enough. For example, some functionality might need to be provided in many views. For these applications, you can apply a mixed split. The following diagram shows a mixed split solution in which micro-frontends for Station finder and Route explorer both use the Map view functionality.

Portal-type or dashboard-type applications typically bring frontend capabilities together in a single view. In these types of applications, each widget can be delivered as a micro-frontend, and the hosting application defines the constraints and interfaces that the micro-frontends should implement.

This approach provides a mechanism for micro-frontends to handle concerns such as viewport sizing, authentication providers, configuration settings, and metadata. These types of applications optimize for extensibility. New features can be developed by new teams to scale the dashboard capabilities.

The following diagram shows a dashboard application developed by three individual teams that are part of Team Dashboard.

In the diagram, the future view represents new features developed by new teams to scale Team Dashboard and the dashboard capabilities.

Portal and dashboard applications usually compose functionality by using a mixed split in the UI. The micro-frontends are configurable with well-defined settings, including position and size constraints.