Monolith: to Plugins #

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

• Vanilla Plugins is the most direct approach which relies on replaceable bits of logic.
• Hexagonal Architecture is a subtype of Plugins which is all about isolating the main code from any third-party components 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 #

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 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 may be required to expose the tunable aspects of the system.
• Testability becomes poor because of the number of possible variants.
• Performance is likely to degrade.

Isolate dependencies with Hexagonal Architecture #

Patterns: Hexagonal Architecture (Plugins).

Goal: isolate the business logic from external dependencies.

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

The main business logic will communicate with all the external components through APIs or SPIs defined in the terms of the business logic. 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) #

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 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 too fine-grained.
• Testability may be an issue.