Architecture Styles

Fundamentals of Software Architecture, an excellent introductory book by Mark Richards and Neal Ford, defines four main steps that compose an architecture: Architecture Characteristics, Structure, Architecture Decisions, and Design Principles. In this post, I want to specifically focus on Structure.

The structure of a system refers to the type of architecture styles (or architecture patterns), each covering a variety of characteristics. It is the responsibility of the architect to define the trade-offs between the pros and cons of each architecture, with the objective of delivering the most accurate style for the specific business.

Architecture styles can be classified into two main types: monolithic (a single deployment unit of code) or distributed (multiple deployments connected using remote access protocols).

Here, we are presenting a short description of each one described in the book.   

 

Layered Architecture Style

Also known as n-tier, is one of the most common, monolithic architecture styles. Layered architecture is a style that divides an application into distinct layers, each responsible for a specific set of functionalities. The typical layers include the presentation layer (user interface), business logic layer (application logic), and data access layer (database interaction). The communication between the layers can be constructed using well-defined interfaces. 

 

Topology:

 

Pros:

• Clear separation of concerns.
• Each layer can be developed and maintained independently.
• Reusability of components within each layer.
• Cost, simplicity.
  

 

Cons:

• Changes in one layer may impact others.
• Can lead to a monolithic design if not managed carefully.
• Deployability, Elasticity, Modularity, Scalability, Fault Tolerancy, Testability.
  

 

Real-world Use Cases:

• MVPs (Minimal Viable Products).
  
• Traditional web applications.
• Enterprise systems with a clear division of responsibilities.

_____________________________________________________________________________

Pipeline Architecture Style

Also known as pipes and filters architecture, the Pipeline is a monolith style where the tasks are organized into a sequential pipeline, each of them responsible for processing a specific input and producing an output. This architecture is well-suited for applications that require high throughput and efficiency, as the tasks can be run in parallel.

 

Topology:

 

 

Pros:

• Simplifies complex processes by breaking them into stages.
• Enables parallel processing in some cases.
•  Cost, Simplicity.

 

Cons:

• May not be suitable for all types of applications.
• Dependencies between stages can introduce bottlenecks.
• Elasticity, Fault Tolerance, Scalability. 
  

 

Real-world Use Cases:

• Continuous Integration/Continuous Deployment (CI/CD) pipelines.
• Data processing pipelines in big data applications.

_____________________________________________________________________________

Microkernel Architecture Style

The Microkernel is also known as plug-in architecture is another monolith architecture, where there is a separation between the core functionality of a system from its periphery. The core functionality is implemented in a small, tightly-coupled kernel, while the periphery is implemented in a set of pluggable modules. This makes it easier to add new functionalities to the system without affecting the core. The core system can be programmed using some variations, like layered architecture, or divided in domain components.

 Topology:

Pros:

• Flexibility and extensibility through independent modules.
• Easier maintenance and updates for individual modules.
• Cost, Simplicity.
  

 

Cons:

• Increased complexity in communication between modules.
• Performance overhead due to inter-module communication.
• Elasticity, Fault Tolerance, Scalability.
  

 

Real-world Use Cases:

• Plugin systems in applications (Jenkins, Eclipse).
• Operating system design with a modular structure.
  

_____________________________________________________________________________

Service-Based Architecture Style

Composed by coarse-grained "portions of an application" or domain-services, the Service-Based is classified as a distributed style, organizing a system into a collection of loosely coupled services, each of which is responsible for a specific business capability. Services communicate with each other through well-defined interfaces. This makes it easier to reuse services, integrate with other systems, and scale the system. 

Topologies variants like multiple user interfaces, the use of API layer, technical or domain partitioning, can occur in this style.

Topology:

Pros:

• Promotes reusability and modularity.
• Easier scalability as services can be distributed.
• Deployability, Fault Tolerance, Cost, Testability.
  

 

Cons:

• Increased network communication may introduce latency.
• Managing service dependencies can be complex.
• Elasticity, Scalability.
  

 

Real-world Use Cases:

• Enterprise-level applications with distributed business processes.
• E-commerce platforms with separate services for inventory, payments, etc.
  

_____________________________________________________________________________

Event-Driven Architecture Style

Pros:

• Scalability and responsiveness to real-time events.
• Decoupling of components allows for flexibility.
• Evolutionary, Fault Tolerance, Performance, Scalability.
  

 

Cons:

• Debugging and tracing events can be challenging.
• Asynchronous communication can introduce complexity.
• Simplicity, Testability, Cost.
  

 

Real-world Use Cases:

• Financial systems processing real-time market data.
• IoT applications reacting to sensor inputs.

_____________________________________________________________________________

Space-Based Architecture Style

The Space-based distributed architecture style separates the system into a set of independent spaces, each responsible for a specific domain. Spaces communicate with each other through a central fabric. This makes it easier to manage and evolve the system, as changes in one space do not affect the other spaces.

 

Topology:

 

Pros:

• Scalability by adding more nodes.
• Fault tolerance through data replication.
• Elasticity, Performance, Scalability, Reliability.
  

 

Cons:

• Increased complexity in managing distributed state.
• Data consistency challenges in distributed systems.
• Simplicity, Testability, Cost.
  

 

Real-world Use Cases:

• High-performance computing applications.
• Online gaming platforms with a large user base.

 _____________________________________________________________________________

Orchestration-Driven Architecture Style

The Orchestration-driven service-oriented architecture is another distributed style that combines SOA and orchestration. SOA defines the services that are available, while orchestration controls the flow of data and control between the services. This makes it easier to integrate services and control the behavior of the system.

 

Topology: 

 

Pros:

• Centralized control over service interactions.
• Easier monitoring and management of the overall system.
•  Scalability

 

Cons:

• Single point of failure in the orchestrator.
• Increased dependency on the central control component.
• Deployability, Evolutionary, Cost, Performance, Reliability, Simplicity, Testability. 
  

 

Real-world Use Cases:

• Workflow management systems.
• Business process automation.

_____________________________________________________________________________

Microservices Architecture Style

 

Topology:

 

Pros:

• Independent development, deployment, and scaling of services.
• Improved fault isolation and resilience.
• Elasticity, Evolutionary, Fault Tolerance, Modularity, Reliability, Scalability, Testability.
  

 

Cons:

• Increased complexity in managing distributed systems.
• Challenges in maintaining consistency across services.
• Cost, Simplicity, Performance.
  

 

Real-world Use Cases:

• Cloud-based applications.
• Large-scale e-commerce platforms.

 _____________________________________________________________________________ 

 

Each of these architecture styles contains variants that must be evaluated, before defining which of them will be used in your solution.

 

I hope you have enjoyed this post. See you next time.