A Little Overview: Popular Software Architectures Nowadays
There are tons of choices and patterns to base your software architecture on. Many architects were before us that have thought of great architectures that many of us use to this day. There are a handful of architectures that are considered the most common or popular. This post will contain a very generic overview of these architectures. If you want to have a more in-depth read on any of these architectures, stick around the blog because a detailed more post about each discussed during this one will appear in the near future.
Three architectures are a popular choice these days. They are the layered architecture, event-driven architecture, and the microservice architecture. The layered architecture is the oldest of the three; the microservice architecture the youngest. The event-driven architecture is used in more specific use cases, but still the most popular choice for this use case.
Layered Architecture
The layered architecture is also called the n-tier architecture. It is the de facto standard for most Java Enterprise applications. It is sometimes perceived as the easiest architecture. In a sense, it is true, because the concept is rather simple. However, applying the architecture can be a whole different story. So, what is the idea behind the n-tier architecture? This architecture organises its components in horizontal layers. Each layer performs a specific role within the application. The amount is up to the software architect, but most use three or four layers. These layers work independently but need information from the layers around them. For instance, if we have three layers, presentation, business, and persistence, and presentation wants to retrieve data from the persistence layer, the request and the response has to go through the business layer.
Event-Driven Architecture
When building a scalable application, architects tend to use the event-driven architecture the most. The concept is also rather simple but can get complex very fast as well when trying to apply it. This architecture works with events instead of requests like the name suggests. There are two flavours to choose from when going for an event-driven architecture: the mediator topology and the broker topology.
If you require centralised event management, the mediator topology is your best choice. It consists of four components: the event mediator, queues, channels, and processors. The mediator is the component that orchestrates the event handling.
When your events are more chain-like, the broker topology is a better candidate over the mediator topology. This topology consists of two components: the event processors and the event channels. All the event channels combined is the broker of the system.
Microservice Architecture
This architecture is the youngest of the bunch. It is still a rather new and evolving pattern. Because it is still evolving, it is unclear how it should be implemented yet. There are several different guidelines, and there is no consensus on a definitive one yet. It definitely needs to mature, but many architects are really positive about it, so we need to give it some time to grow. However, there is a set of core concepts for applying this architecture pattern. The microservice architecture consists of separately deployed units. These units are service component and are distributed in nature. By using these concepts, the microservice architecture tries to fix common issues from the layered and service-oriented architectures.
These are the three most popular architectures of this day. With the knowledge of their concepts, you can already start working with these architectures in your own applications. Of course, there is more to each architecture than I can tell you in just one post. That’s why I’ll be writing more in-depth posts about each architecture in this post and other architectures.