Evolutions of a Monolith that rely on Plugins

The last group of evolutions which we will review does not really change the monolithic nature of the application. Instead, its goal is to improve the customizability of the Monolith:

Vanilla Plugins are the most direct approach which relies on tailorable bits of logic.
Hexagonal Architecture is a subtype of Plugins which is all about isolating the main code from any third-party components which it uses.
Scripts is a kind of Microkernel – yet another subtype of Plugins – which gives users of the system full control over its behavior.

Support plugins#

Plugins customize the monolith's behavior.

Patterns: Plugins.

Goal: simplify the customization of the application’s behavior.

Prerequisite: several aspects need to vary from customer to customer.

Plugins create points of access to the system that allow engineers to collect data and govern select aspects of the system’s behavior without having to learn the system’s implementation.

Pros:

The system’s behavior can be modified by internal and external programmers who don’t know its internal details.
Customized versions become much easier to release and support.

Cons:

Extensive changes in the code may be required to expose the tunable aspects of the system.
Testability becomes poor because of the large number of possible variants.
Performance is likely to degrade.

Isolate dependencies with Hexagonal Architecture#

The database, external libraries, and a protocol support component are separated from the business logic and isolated with adapters.

Patterns: Hexagonal Architecture (Plugins).

Goal: isolate the business logic from its external dependencies.

Prerequisite: there are third-party or frequently changing components in the system.

The main business logic will communicate with any external component through an API or SPI defined in the terms of the business logic itself. This way it will not depend on anything at all, and any component will be replaceable with another implementation or a stub/mock.

Pros:

Vendor lock-in is ruled out.
A component may be replaced through to the very end of the system’s life cycle.
Stubs and mocks are supported for testing and local or early development.
It is possible to provide multiple implementations of a component.

Cons:

Some extra effort is required to define and use the interfaces.
There is performance degradation, mostly due to lost optimization opportunities.

Add an Interpreter (support Scripts)#

The high-level logic is rewritten as scripts which are run by an interpreter.

Patterns: Scripts aka Interpreter (Microkernel (Plugins)).

Goal: allow the system’s users to implement their own business logic.

Prerequisite: the domain is representable in high-level terms.

Interpreter lets the users develop high-level business logic from scratch by programming interactions of pre-defined building blocks, which are implemented in the core of the system. That provides unparalleled flexibility at the cost of degraded performance and design complexity.

Pros:

Perfect flexibility and customizability for every user.
The high-level business logic is written in high-level terms, making it fast to develop and easy to grasp.

Cons:

Requires much effort to design correctly.
There may be a heavy performance penalty if the API is overly fine-grained.
Testability may be an issue.