Ambiguous patterns #

We’ve seen a single pattern come under many names, as happens with Orchestrator, and also one name used for multiple topologies, as with Services, which may orchestrate each other, make a Pipeline, or be components of the Service-Oriented Architecture (SOA). On top of that, there are several pattern names that are often believed to be unambiguous while each of them sees conflicting definitions in books or over the web (thanks to Semantic Diffusion or independent coining of the term by multiple authors). Let’s explore the last kind, which is the most dangerous both for your understanding of other people and for your time wasted in arguments.

Monolith #

The old books, namely [GoF] and [POSA1], described a tightly coupled unstructured system, where anything depends on everything, as monolithic, which matched the meaning of the word in Latin – “single stone”.

Then something evil happened – I believe that the proponents of SOA, backed by the hype and money they had earned from corporations, started labeling any non-distributed system as monolithic, obviously to contrast the negative connotation of the word to their own most progressive design.

It took only a decade for the karma to strike back – when the new generation behind Microservices redefined monolithic as a single unit of deployment – to call the now obsolescent SOA systems Distributed Monoliths [MP] because their services used to grow so coupled that they had to be deployed together.

The novel misnomers, Layered Monolith [FSA] and Modular Monolith [FSA], which denote an application partitioned by abstractness or subdomain, correspondingly, add to the confusion.

Reactor #

People tend to call any event-driven service a Reactor. In fact, there are three patterns that describe threading models for an event-handling system:

• A Reactor [POSA2] runs each task in a dedicated thread and blocks it on any calls outside of the component. That allows for normal imperative programming but is resource-consuming and not very responsive or flexible.
• A Proactor [POSA2] relies on a single thread to serve all the system’s tasks in an interleaved manner, just like an OS uses a CPU core to run multiple processes. The resulting non-blocking code is fragmented (thus known as callback hell) but it can address any incoming event immediately. This suits real-time control systems.
• Half-Sync/Half-Async [POSA2] is what we know better as coroutines or fibers – there are multiple Reactor-like lightweight threads that block on a Proactor-like engine which translates between synchronous calls from the user code and asynchronous system events.

In most cases we’ll hear of Proactor being called Reactor – probably because Reactor was historically the first and the simplest of the three patterns, and it is similar in name to reactive programming found in Proactor.

Microkernel #

Microkernel is another notable case. The confusion over it goes all the way back to [POSA1] which used operating systems as examples of Plugin Architecture. I believe that it was a mismatch:

• An operating system is mainly about sharing the resources of producers among consumers, where both the producers and consumers may be written by external teams. The kernel itself does not feature much logic – its role is to connect the other components together.
• Plugins, on the other hand, extend or modify the business logic of the core – which alone is the reason for the system to exist and is in no way “micro-” as it got the bulk of the system’s code. In many such systems plugins are utterly optional – which cannot be said of OS drivers.

Thus, here we have two architectural patterns of arguably similar structure (Microkernel/Plugins of [SAP, FSA] omit 3 of 5 components of the original Microkernel of [POSA1, POSA4]) but very different intent and action known under the same name.

Domain Services #

I was told that Domain Services of [FSA] are an incorrect term – because a domain service is always limited to the domain layer of [DDD] while those of [FSA] also cover the application and, maybe, infrastructure.

I believe that both definitions are technically correct, if the difference in the meaning of domain is accounted for. In [FSA] domain is almost synonymous with a bounded context of [DDD], while [DDD] more often uses that word for the name of its middle layer which contains business rules.

Service-Based Architecture #

[DEDS] calls anything service-based a service-based architecture.

[FSA] differentiates Microservices and Service-Oriented Architecture, leaving whatever remains (large subdomain-scale services) under the name of Service-Based Architecture.

Both definitions are technically correct. One is wider than the other.

Front Controller #

[PEAA] defines Front Controller as an MVC derivative for backend programming. In this pattern multiple web pages share a request processing component which turns the incoming requests into commands and forwards them to appropriate page classes.

The definition from [SAHP] is much more interesting – it describes an Choreographed Event-Driven Architecture with a Query Service embedded in the first (client-facing) service. The Front Controller subscribes to notifications from downstream services to know the status of every request it has passed to the pipeline.

Cells #

The fresh Cell-Based Architecture also has multiple definitions.

• WSO2 wrote about a Cell as a group of services which is encapsulated from the remaining system by a Gateway (for incoming traffic) and sometimes Adapters (for outgoing traffic) and often uses a dedicated Middleware – causing each Cell, though internally distributed, to be treated by other components as a single service. This makes designing and managing a large system a bit simpler by introducing a hierarchy.
• Amazon promotes its Cells as Shards of the whole system which run in multiple geographic regions. That grants fault tolerance and improves performance as each client has an instance of the system deployed to a nearby datacenter, but it does not have much impact on organization and complexity of the code.

This case looks like Amazon’s hijacking and redefining a popular emerging technology, though I may be wrong about that as I did not investigate the history of the term.

Nanoservices #

The Nanoservices pattern is another emerging technology and it seems to have never been strictly defined. Most sources agree that a nanoservice is a cloud-based function (FaaS), similar to a service with a single API method but, just as with the old good services, they differ in the ways they use the novel technology:

• Diego Zanon in Building Serverless Web Applications proposes a single layer of nanoservices, each implementing a method of the system’s public API, to be used as a thin backend.
• Here we have nanoservices built into a Pipeline, similar to Choreographed Event-Driven Architecture [FSA].
• Another article proposes to (re)use them in SOA style.

Moreover, there are a couple of sources that call a nanoservice something totally different:

• There is a concept of nanoservice as a module that can run both as a separate service and as a part of a binary – allowing for a team to choose if they want their system to run as a single process or become distributed. Nano- is because an in-process module is more lightweight than a microservice. This idea resembles Modular Monolith [FSA] and Actor Frameworks.
• And here we have something akin to Space-Based Architecture but it is also called Nanoservices – as the proposed framework makes new components so easy to create that programmers tend to write many smaller nanoservices instead of a single microservice.

In my opinion, the disarray happened because the notion of making smaller microservices got hyped but was never adopted widely enough to become an industry standard, therefore everybody follows their own vision about what smaller means.

Summary #

A few names of architectural patterns cause confusion as the meaning of each of them changes from source to source. This book aims at identifying such issues and building a cohesive understanding of software and system architecture, similar to the ubiquitous language of [DDD].