Table of Contents
In the Global Software Architecture Summit we were discussing software architecture patterns a lot and I decided to write an article about it, highlighting leading software architects insights.
First of all, what are software architecture patterns?
Architectural patterns are ways of capturing proven good design structures, so that they can be reused. Software architects have been looking for ways to capture and reuse the architectural knowledge that have proven successful in the past.
More specifically, an architectural pattern is a package of design decisions that is found repeatedly in practice, has well defined properties that can be reused and describes a class of architectures.
Developing an architecture can be seen as a process of selecting, tailoring, and combining patterns. The software architect must decide how to instantiate a pattern, how to make it fit with the specific context and the constraints of the problem. And later on we will discuss it more in details.
Mark Richards wrote a book called “Software Architecture Patterns” according to him, there are 5 major software architecture patterns: microkernel, microservices, Layered architecture, event-based, and space-based. Btw, if you would like to meet Mark in person, he will give a hands-on workshop in Global Software Architecture Summit in Barcelona ( October, 1-2 ) or you can attend his more extended workshop in Apium Academy.
5 major Software Architecture patterns
The microkernel architectural pattern is also referred to as a plug-in architectural pattern. It is typically used when software teams create systems with interchangeable components.
It applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. Itl also serves as a socket for plugging in these extensions and coordinating their collaboration.
The microkernel architecture pattern is a natural pattern for implementing product-based applications. And a product-based application is one that is packaged and made available for download in versions as a typical third-party product. However, many companies also develop and release their internal business applications like software products, complete with versions, release notes, and pluggable features.
The microkernel architecture pattern allows you to add additional application features as plug-ins to the core application, providing extensibility as well as feature separation and isolation.
The microkernel architecture pattern consists of two types of architecture components: a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic. And the core system of the microkernel architecture pattern traditionally contains only the minimal functionality required to make the system operational.
Perhaps the best example of the microkernel architecture is the Eclipse IDE. Downloading the basic Eclipse product provides you little more than an editor. However, once you start adding plug-ins, it becomes a highly customizable and useful product.
- Great flexibility and extensibility
- Some implementations allow for adding plug-ins while the application is running
- Good portability
- Ease of deployment
- Quick response to a constantly changing environment
- Plug-in modules can be tested in isolation and can be easily mocked by the core system to demonstrate or prototype a particular feature with little or no change to the core system.
- High Performance as you can customize and streamline applications to only include those features you need.
- Applications that take data from different sources, transform that data and writes it to different destinations
- Workflow applications
- Task and job scheduling applications
When you write your application as a set of microservices, you’re actually writing multiple applications that will work together. Each microservice has its own distinct responsibility and teams can develop them independently of other microservices. The only dependency between them is the communication. As microservices communicate with each other, you will have to make sure messages sent between them remain backwards-compatible.
- You can write, maintain, and deploy each microservice separately
- Easy to scale, as you can scale only the microservices that need to be scaled
- It’s easier to rewrite pieces of the application because they’re smaller and less coupled to other parts
- New team members must quickly become productive
- The application must be easy to understand and modify
- Highly maintainable and testable – enables rapid and frequent development and deployment
- Independently deployable – enables a team to deploy their service without having to coordinate with other teams
- Websites with small components
- Corporate data centers with well-defined boundaries
- Rapidly developing new businesses and web applications
- Development teams that are spread out, often across the globe
3.Layered architecture pattern
The most common architecture pattern is the layered architecture pattern. Layered architecture patterns are n-tiered patterns where the components are organized in horizontal layers. This is the traditional method for designing most software and is meant to be self-independent. This means that all the components are interconnected but do not depend on each other. Each layer of the layered architecture pattern has a specific role and responsibility within the application. For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request.
One of the powerful features of the layered architecture pattern is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer.
- High testability because components belong to specific layers in the architecture, other layers can be mocked or stubbed, making this pattern is relatively easy to test.
- High ease of development because this pattern is so well known and is not overly complex to implement, also most companies develop applications by separating skill sets by layers, this pattern becomes a natural choice for most business-application development.
- Easy to assign separate “roles”
- Easy to update and enhance layers separately
- Standard line-of-business apps that do more than just CRUD operations
- New applications that need to be built quickly
- Teams with inexperienced developers who don’t understand other architectures yet
- Applications requiring strict maintainability and testability standards
This is the most common distributed asynchronous architecture used to develop highly scalable system. The architecture consists of single-purpose event processing components that listen on events and process them asynchronously. The event-driven architecture builds a central unit that accepts all data and then delegates it to the separate modules that handle the particular type.
- Are easily adaptable to complex, often chaotic environments
- Scale easily
- Are easily extendable when new event types appear
- Asynchronous systems with asynchronous data flow
- User interfaces
5. Space-based pattern
The space-based architecture pattern is specifically designed to address and solve scalability and concurrency issues. It is also a useful architecture pattern for applications that have variable and unpredictable concurrent user volumes. High scalability is achieved by removing the central database constraint and using replicated in-memory data grids instead.
The space-based architecture is designed to avoid functional collapse under high load by splitting up both the processing and the storage between multiple servers.
- Responds quickly to a constantly changing environment.
- Although space-based architectures are generally not decoupled and distributed, they are dynamic, and sophisticated cloud-based tools allow for applications to easily be “pushed” out to servers, simplifying deployment.
- High performance is achieved through the in-memory data access and caching mechanisms build into this pattern.
- High scalability come from the fact that there is little or no dependency on a centralized database, therefore essentially removing this limiting bottleneck from the scalability equation.
- High-volume data like click streams and user logs
- Low-value data that can be lost occasionally without big consequences
- Social networks
I hope you found this article useful, if you believe there are other patterns that should be listed here, feel free to share them in the comments section below! And if you have any questions, send us a message, we would be happy to help, as this is our expertise!