Layers: make more layers #

Not all the layered architectures are equally layered. A Monolith with a Proxy or database has already stepped into the realm of Layers but is far from reaping all of its benefits. It may continue its journey in a few ways that were earlier discussed for Monolith:

Employing a database (if you don’t use one) lets you rely on a thoroughly optimized state-of-the-art subsystem for data processing and storage.
Proxies are similarly reusable generic modules to be added at will.
Implementing an Orchestrator on top of your system may improve programming experience and runtime performance for your clients.

Layers to Layers

It is also common to:

Segregate the business logic into two layers.

Split the business logic into two layers #

Layers Split in Two

Patterns: Layers.

Goal: let parts of the business logic vary in qualities, improve the structure of the code.

Prerequisite: the high-level and low-level logic are loosely coupled.

It is often possible to split a backend into integration (orchestration) and domain layers. That allows for one team to specialize in customer use cases while the other one delves deep into the domain knowledge and infrastructure.

Pros:

You get an extra development team.
High-level use cases may be deployed separately from business rules.
The layers may diverge in technologies and styles.
The code may become less complex.

Cons:

There is a small performance penalty.
In-depth debugging becomes harder.