I have been thinking a lot lately about how to classify software architecture patterns. Until recently, I've never really had the need to do so, but of late I've been needing to package them together in some sort of classification (or taxonomy). Certainly the three main service patterns (Microservices architecture, service-oriented architecture, and service-based architecture) all fit together nicely into what I like to call "service-based patterns", but what about other types of non-service patterns such as the layered architecture, microkernel architecture, event-driven architecture, and so on?
Any classification scheme should be based on some sort of context or purpose. At first I thought it might be a good idea to base some sort of classification on the way components are thought of in the architecture (e.g., services or components). Given the rise in service architectures, this seemed like a good idea. However, this classification quickly fell apart when taking event-driven architecture into account. Event-driven architecture is not service-based (its components are called event processors, not services), but it shares many of the characteristics of service-based patterns.
So I started thinking about the overall style of the architecture, and what I finally came up with was the distinguishing factor of whether or not the architecture is a distributed one. This classification makes much more sense because the characteristics shared by distributed architectures are similar (scalable, elastic, decoupled, remote, and complex). So, given this classification scheme between monolithic styles and distributed styles, here I what I came up with for some of the more common architecture patterns:
Monolithic Architecture Patterns
- Layered Architecture
- Microkernel Architecture
- Pipes and Filter (Pipeline) Architecture
Distributed Architecture Patterns
- Event-Driven Architecture
- Space-Based Architecture
- Microservices Architecture
- Service-Oriented Architecture
- Service-Based Architecture
Monolithic architecture patterns generally allow for better performance (due to the lack of remote access protocols), are less complex, and are generally easier to develop and test. Distributed architectures, on the other hand, generally provide better scalability, elasticity, ease of deployment, and promote modular and decoupled applications, but are harder to develop and test due to all of the issues associated with distributed computing (reliability, timeouts, performance, remote access, contract maintenance, transactions, and so on).
This classification is certainly far from perfect. For example, while the Layered Architecture pattern tends to lead towards monolithic applications, you can just as easily distribute the layers (specifically the presentation layer and the business layer as separate applications), thereby creating a distributed architecture. However, while this practice was feverishly pursued in the early 2000's, these days it's not as common due to the performance implications associated with distributed layered architectures.
I will likely be moving forward with this pattern taxonomy until another one proves more useful. While I really like classifying service-based patterns separately, I'm happy with this because the word "service" occurs in the pattern name itself, which is enough of a distinction for me. So “monolithic” vs. “distributed” it is for the time being...