Software Architecture & Design, Part II: Well-Known Architectural Patterns and Difference with Design Patterns
In Software Architecture & Design, one of the most important decisions is the design patterns for the components and subcomponents. Now we have an important task to distinguish Architectural pattern from Design pattern or vice versa. What is the difference?
If you have read my article “Software Architecture & Design Part I”, you probably feel the difference. Architectural Pattern belongs to Design phase of the SDLC (Software Development Life Cycle), where Design Pattern is in Development phase. Which means we need to have firstly decision of architectural pattern then design pattern.
Architectural pattern is a higher-level scope, in other words, deals with overall structure of the system. As we discussed the definition of it, architectural pattern is about “how components are organized and assembled”. On the other hand, Design pattern has lower-level scope. Rather then how components are organized, it is about how components are built.
I think now we have clear idea about both patterns. I mentioned that they are in different scopes, but it doesn’t mean that they have nothing to do with each other. Developers have a right to choose whatever design pattern they want. However, choice of architectural pattern sometimes affect this decision. For instance, for chosen architectural pattern ‘A1’, it is impossible to apply design pattern ‘D1’. To sum up, choice of architectural pattern can have impact on choice of design pattern due to fact that architectural pattern is predicate.
Now, let’s deep dive in Architectural Patterns. Architectural patterns are divided into 2 levels and grouped in different classes.
Level 1 is more of a high-level classification which categorizes architectural patterns into “Monolithic Architectures”, “Service-based Architectures”(or Service-oriented) and “Distributed Architectures”.
Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program. These kinds of applications are easy to develop and deploy, but in large systems, it has several drawbacks such as maintenance, reliability, scalability and more.
Service-oriented architecture is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. This architecture fits well with web-based systems. It is costly as it requires high bandwidth servers.
In Distributed architecture, components are presented on different platforms and several components can co-operate with one another over a communication network in order to achieve a specific objective or goal. In the case of concurrency and resource sharing this architecture is a great choice. And it is fact that distributed systems are much more complex than centralized systems in case of manageability and security.
In Level 2, we have “Layered Pattern”, “Microservices Pattern”, and “Event-Driven Pattern” and more. In next few sentences, let’s talk about some of those patterns briefly.
Layered pattern (also called N-tier) lend itself towards a monolithic architecture at the core. You’ve most likely seen it before. In this pattern, you’ll find the software divided into the Presentation, Business, Persistence, and Database layers. Related functionalities are grouped together. The system achieves communication of these layers via APIs.
Microservices pattern is a service-oriented architecture. It deals with services and characterized by independently evolvable and deployable units. System doesn’t break by adding or removing these units and these units form the whole system by some sort of coordination.
Event-driven pattern is a distributed architectural pattern. It consists of multiple distributed computing or event processing units that are coordinated and coupled using one of the two topologies; Mediator topology or the Broker topology (These topologies are the topic of upcoming articles). This pattern is used for applications that need to be highly scalable and dynamic. Event-driven systems could have many structures depending on the topology used.
Microkernel pattern which is also referred as the plugin pattern has two major components. The core system which is meant to have the minimal functionalities, and the plugins that are used to customize the software and add features to it. This pattern has a monolithic nature. Some applications of this pattern are web browsers, text editors, and operating systems.
Space-based pattern is sort of hybrid pattern that takes advantage of microservices, event-driven and some computer science concepts. Actually, it is inspired by the top of space implementation which is used in concurrent distributed systems. Basically, it works through distributed caching which is “In Memory Data Grid” that is shared among multiple processing units which are independent from each other. These processing units are managed by a “Middleware” that has four core components; “Messaging Grid”, “Data Grid”, “Processing Grid, and “Deployment Manager”. This pattern is known for its elasticity and high scalability. Cloud is one implementation of it.
We have reached the end of 2nd and final part of my article “Software Architecture and Design”. In this part, we have talked about some well-known Architectural Patterns, and general differences between Architectural Patterns and Design Patterns. Note that, they are also other architectural patterns out there that we haven’t talked in this article. For further knowledge, you can refer to the books “Pattern-Oriented Software Architecture” and “Software Architecture in Practice”.
