Good architecture is something that supports its own evolution, and is deeply intertwined with programming [Martin Fowler]

Here I'll list a set of architecture patterns distributed in three different categories: Landscape, Structure and UI. The first one is a general way to define the solution (as a map of a city), the second one is more specific how to separate parts of the application (as a house), and the third one is related to UI.

Landscape Structure UI
  • Monolithic
  • N-Tier
  • SOA
  • Microservice
  • Serveless
  • Peer-To-Peer
    		•
  • Layered
  • Microkernel
  • Event Sourcing
  • CQRS
  • Hexagonal
    		•
  • MVC
  • MVP
  • MVVM
    		•

    Landscape

    Monolith

    The idea is to have all parts of code together, or self-contained. All parts will create one deployment unit. It is modular software where all components are together to be compiled and executed. It means if one part is updated the whole application should be compiled and deployed again. However, comparing with a modular application, it has better throughput and is easier to test and debug.


    Sources: Igor Omelchenko (clockwise)

    References


    N-Tier

    N-tier application architecture provides a model by which developers can create flexible and reusable applications. A three-tier architecture is typically composed of a presentation tier, a domain logic tier, and a data storage tier. (Wiki)

    Difference between layer and tier: the first one concerns a logical solution, while a tier is a physical solution.

    References


    SOA

    The service-oriented architecture has multiple services where each one is a business activity. Those services can communicate with each other because of a contract standardization, as SOAP. The SOA has ESB (enterprise service bus) to centralize the communication of the services, doing routing, translate data, etc. The services are loosely coupled, scalability, no duplication of functionality. However, cannot be so agile to develop.


    Sources: Packt

    References


    Microservice

    It is a natural evolution of the SOA. In this case, the ESB doesn't exist anymore. Microservice can be more agile, easier to develop and deploy new versions. As well, it gives low-coupled modules. Problems in some services will not impact other services. It also comes with some challenges as debug the application and ensure security between the services communication.


    Sources: Igor Omelchenko (clockwise)

    References


    Serveless

    Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. [Martin Fowler]
    Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers.[RedHat]
    Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers. A serverless application runs in stateless compute containers that are event-triggered (http requests, database events, queuing services, monitoring alerts, file uploads), and fully managed by the cloud provider. The code that is sent to the cloud provider for execution is usually in the form of a function. . [GlobalDots]

    BaaS gives developers access to a variety of third-party services and apps.[RedHat]

    Function-as-a-Service (FaaS) is an event-driven computing execution model where developers write logic that is deployed in containers fully managed by a platform, then executed on demand.[RedHat]


    Source: Robin Weston (gocd.org/)

    References


    Peer-to-Peer

    The P2P architecture is a commonly used computer networking architecture where:

    The same device acts as a client and as a server in this arrangement. In its pure form, there is no separate server or centralized point of control. This means that every client also simultaneously acts as a server. Therefore all devices connected to peer-to-peer architecture can simultaneously initiate requests and fulfill requests from each other. [ScienceDirect]


    References


    Structure

    Layered

    The application can have many layers and each one has a distinct responsibility, having as a feature the separation of concerns. Also, the requests go through layers from the direction up to down. The idea is that the layer can go down in the sequence of the layer, but not to call a super layer. It is easy to organize but needs to write lots of code.

    Generically, there are five layers, not mandatory. You will decide the best choice for your application.

    References


    Microkernel

    It is the plugin pattern, where the main part is the core which is connected to many plugins. The idea is to create a package and let it available to be used (product-based application). So, this pattern makes it possible to add new functionality by just plug an extension. This architecture is very flexible, the core and extensions can be developed by different teams, which makes it easy to turn off some functionality in runtime. However, the core API might not fit future plugins and there are no guarantees about the plugins. Also, at the same time might not be so clear what is the core and what is extensions. This pattern can be seen on browser extensions or data processing, for example.

    References


    Event Sourcing

    It store events instead current state.This pattern allow track what happen to a entity by events. One use is audit trail.

    Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.[Martin Fowler]

    References


    Command and Query Responsibility Segregation (CQRS)

    This pattern will separate two distinct models: ready/query (get data - return a DTO) and write/command (insert, update, delete - return an event). It allows scenario-specific queries, improving performance and simplifies the queries. It is possible to have a database to read and others to write to improve the performance.


    Source: Martin Fowler

    References


    Hexagonal

    The main idea is to separate the business from all technical dependence. The core has the business and the external parts have part of the application with technical dependencies. The border of the core has plugins to allow communication between the external parts and the core. The plugins are Port represented by interfaces with the rules of the communication. To make the request from the external part match with the plugin there are the Adapters. It is TDD oriented, business-focused, use Separation of Concept.

    The external parts can be identify in two sides:

    • Drivers: Who start the communication with core (GUI, Rest). The Ports used on that side should be mapped in use cases.
    • Driven: Who receives requests from the core (Repository, Recipient). The Ports use on this side are called SPI (Service Provider Interface)

    The Adapters should be created to each technology. On the driven side you can create mocks to simulate database, for example, and not block the business development. Furthermore, here is used Inversion of Control (IoC) to ensure the concept that the core is independent.

    The core can be implemented using different patterns as Domain Model, Service Layer, Anemic Domain Model, Domain Driven Design (DDD), Clean Architecture.


    Sources: Tom Hombergs - reflectoring.io

    More detail about it you can see in this post where I show a skeleton how to start the project.

    References



    UI

    MVC

    This pattern separate the application in three logic parts: Model (Data) , View (interaction with the user), Controller (connection between Model and View). View and Model should not communicate with each other directly but through the Controller. The Controller is responsible for part of the logic. It makes possible independent development to the frontend and backend. The user Interaction is handled by Controller. The code UI is minimal.


    Sources: Guru99

    References


    MVP

    It is an alternative to MVC because removes logic from Controller, removing the controller idea and adding a mediator, the Presenter, which lets the decisions to View and the logic to Model. It has a passive view. Each Presenter manages one View, different from the Controller which can handle more than one. The user Interaction is handled by View. It has more code in UI.


    Sources: Rakshit Soral

    References


    MVVM

    It is a pattern to use more deep the data binding idea, which makes it possible to get data from the model. The difference between ViewModel and Presenter is ViewModel doesn't have references to view. It's great for desktop and mobile applications. The user Interaction is handled by View. The code UI is minimal.

    The view model is responsible for presenting functions, commands, methods, to support the state of the View. It is also accountable to operate the model and activate the events in the View. [Guru99]


    Sources: Guru99

    References

    References