Evolutions of Layers to gain flexibility

Evolutions of Layers to 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.
Monolith to Layers - Further 2

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#

Layers to 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: