Layers: gain flexibility #

The last group of evolutions to consider is about making the system more adaptable. We have already discussed the following evolutions for Monolith:

• The behavior of the system may be modified through Plugins.
• Hexagonal Architecture protects the business logic from dependencies on libraries and databases.
• Scripts allow for customization of the system’s logic on a per client basis.

There is also a new evolution that modifies the upper (orchestration) layer:

• The orchestration layer may be split into Backends for Frontends to match the needs of several kinds of clients.

Divide the orchestration layer into Backends for Frontends #

Patterns: Layers, Backends for Frontends aka BFFs.

Goal: let each kind of client get a dedicated development team.

Prerequisite: no high-level logic is shared between client types.

It is possible that your system has different kinds of users, e.g. buyers, sellers, and admins; or web and mobile applications. It may be easier to support a separate integration module per kind of client than to keep all the unrelated code together in a single integration layer.

Pros:

• Each kind of client gets a dedicated team which may choose best fitting technologies.
• You get rid of the single large codebase of the integration layer.

Cons:

• There is no good way to share code between the BFFs (in naive implementation).
• There are new components to administer.

Further steps:

• Evolve the BFFs through adding a shared layer or Sidecars for common functionality.