Why should you learn at least the basic Architecture Patterns as Software Engineer?

I believe there are many articles answering to this question, but I will give you a few reasons to consider. First of all, if you know the basics of architecture patterns, then it is easier for you to follow the requirements of your architect. Secondly, knowing those patterns will help you to make decisions in your code: for example, if your application design is based on event-driven microservices, as a software engineer you must decouple your code into a separate service should you notice the increasing complexity and responsibility of logic in the existing service. (If you didn’t get this part, just follow the text, where this pattern is briefly explained).

There are 5 patterns described in the book by Mark Richards:

• Layered architecture
• Event-driven architecture
• Microkernel architecture (or Plugin architecture)
• Microservices architecture
• Space-based architecture (or Cloud architecture pattern)

1. Layered architecture

It is the most common architecture for monolithic applications. The basic idea behind the pattern is to divide the app logic into several layers each encapsulating specific role. For example, the Persistence layer would be responsible for the communication of your app with the database engine.

2. Event-driven architecture

The idea behind this pattern is to decouple the application logic into single-purpose event processing components that asynchronously receive and process events. This pattern is one of the popular distributed asynchronous architecture patterns known for high scalability and adaptability.

3. Microkernel Architecture

Mikrokernel Architecture, also known as Plugin architecture, is the design pattern with two main components: a core system and plug-in modules (or extensions). A great example would be a Web browser (core system) where you can install endless extensions (or plugins).

4. Microservices Architecture

Microservices architecture consists of separately deployed services, where each service would have ideally single responsibility. Those services are independent of each other and if one service fails others will not stop running.

5. Space-Based Architecture

The main idea behind the space-based pattern is the distributed shared memory to mitigate issues that frequently occur at the database level. The assumption is that by processing most of operations using in-memory data we can avoid extra operations in the database, thus any future problems that may evolve from there (for example, if your user activity data entity has changed, you don’t need to change a bunch of code persisting to & retrieving that data from the DB).

The basic approach is to separate the application into processing units (that can automatically scale up and down based on demand), where the data will be replicated and processed between those units without any persistence to the central database (though there will be local storages for the occasion of system failures).