Comparison Table: Software Architectural Styles

Comparison Table: Software Architectural Styles.md

Architectural Style	Definition	Techical Concepts
Asynchronous Messaging	Pattern where the sender and receiver of a message don't need to interact with the message queue at the same time	- Decoupling: This refers to the lack of a direct connection between the sender and receiver, allowing them to operate independently - Message Exchange Architectures: These are structures designed for transferring messages between a sender and receiver - Eventual Consistency: This concept suggests that changes made to one service may potentially lead to unintended and negative consequences in other parts of the system
Blackboard	Decentralized problem-solving model that uses a modular approach. It’s designed to tackle complex problems that don’t have a clear algorithm or pre-set architecture	- Initialization: The blackboard is prepared with the initial problem statement and any available input data - Activation: Based on the current state of the problem and the data on the blackboard, the controller selects and activates one or more knowledge sources - Execution: The activated knowledge sources independently analyze the problem, apply their specialized algorithms or techniques, and produce partial solutions or hypotheses - Conflict resolution: If multiple knowledge sources generate conflicting or overlapping solutions, a conflict resolution mechanism is used to reconcile the differences and select the most appropriate solution(s) - Update: The knowledge sources update the blackboard with their outputs, such as new constraints, proposed solutions, or intermediate results - Iteration: The controller repeats the activation and execution steps until a satisfactory solution is reached, convergence criteria are met, or a predefined time limit is exceeded
Client-Server	Model of interaction in a distributed system where software runs on local client devices and connects to remote server resources	- Loose coupling: Clients and servers are separate entities that communicate over a network - Horizontal scaling: Servers can be added to handle increased load - Distributed database: Data can be stored across multiple servers, improving availability and performance - Asynchronous communication: Clients make requests to servers and continue processing until the server responds - Stateless or stateful: Servers can be designed to be stateless for scalability or stateful for simplicity
Cloud Computing Patterns	Adapting to the many new possibilities but very different set of architectural constraints offered by the cloud compared to traditional on-premises infrastructure	- Functional requirements: What the system should do - Non-functional requirements: How the system should perform - Constraints: What is out-of-scope to change - Self-healing: The system should be able to recover from failures automatically - Cost efficient: The system should make optimal use of resources to minimize costs - Continuous Integration/Continuous Delivery (CI/CD): The system should be easily updated and maintained
Component-Based	Framework for building software based on reusable components. It provides a higher level of abstraction and divides the problem into sub-problems, each associated with component partitions	- Components: The building blocks that are highly flexible, modular, and reused across several projects. They follow repeatable conventions and can be used across other interfaces and modules without compromising the integrity of your code or UX - Interfaces: Well-defined communication interfaces containing methods, events, and properties - Contracts: Define the functionality provided by the component and the functionality required from the system to be operational - Component models and frameworks: Define standards for component implementation, composition, and deployment - Composition: The way components are assembled to form a system - Certification: The process of verifying that a component meets its specification
Database-Centric	Treats data as a valuable and versatile asset, acknowledging its role in the larger enterprise and industry ecosystem	- Centralized Data: This refers to data that is collected and stored in one place, allowing for frequent access and modification by various components - Security, Integration, Portability, and Analysis: These aspects are significantly simplified in a data-centric approach, which also facilitates faster insights across the entire data value chain - Interoperability and Versatility: By freeing data from a single monolithic stack, there are greater opportunities for accelerating digital transformation
Domain-Driven Design (DDD)	Architecture style that focuses on modeling business domains and their logic in code	- Domain model: A central, conceptual model of the business domain that is used to guide the design of the application - Bounded context: A self-contained model that represents a specific aspect of the business domain - Ubiquitous language: A shared language that is used across the entire development team to describe the domain model
Event-Driven	Design pattern that organizes the application around the production, transformation, and consumption of events	- Event sources: Services or systems that generate events - Event processors: Services or systems that consume and process events - Event stores: Systems that store events for later processing
Layered	Architecture that separates the application into distinct layers, each with its own set of responsibilities	- Logical separation of components: Components that are related or similar are usually placed on the same layers - Layers of isolation: Layers can be modified and the change won't affect other layers - Separation of concerns: The modules on a single layer together perform a single function
Microkernel	A type of operating system kernel that is designed to provide only the most basic services required for an operating system to function	- Minimal functional core: It only runs the most essential services in kernel space, such as low-level address space management, thread management, and inter-process communication (IPC) - User-level processes: Services like device drivers and file systems are implemented as user-level processes. They communicate with the microkernel via message passing - Modularity and flexibility: The system is designed in a way that makes it easy to add, remove, or replace services without affecting other parts of the system
Model–View–Controller	Design pattern that separates an application into 3 interconnected components: the model, the view, and the controller	- Model: The heart of the system, managing the data, logic, and rules of the application - View: Represents any output of information - Controller: Accepts input and transforms it into commands for either the model or view
Monolithic Application	Single, self-contained unit that includes all the components and functionality of the application	- Tight coupling: Components are closely integrated and communicate directly with each other - Vertical scaling: The entire application is deployed and scaled as a single unit - Shared database: A single database is used to store all data for the application
Multitier Architecture	Client–server architecture in which presentation, application processing, and data management functions are physically separated	- N-tier architecture: This is a software engineering approach where processing, data management, and presentation functions are physically and logically separated - Three-tier architecture: This architecture consists of 3 components: a presentation tier, a logic tier, and a data tier - Layer vs Tier: A layer refers to the logical structure of elements in a software solution, while a tier refers to the physical structure of hardware elements in the system infrastructure
Object Request Broker	Middleware architecture used in distributed computing to coordinate and enable communication between registered servers and clients	- Language Independence: CORBA is not associated with a particular programming language, and any language with a CORBA binding can be used to call and implement CORBA objects - Interface Definition Language (IDL): Objects are described in a syntax called IDL - Object Request Broker (ORB): The ORB handles the communication, marshaling, and unmarshaling of parameters so that the parameter handling is transparent for a CORBA server and client applications - Naming Service: The naming service holds references to CORBA objects
Peer-to-Peer	Network architecture where each workstation, or node, has the same capabilities and responsibilities	- Decentralized: Tasks are distributed among all peers, eliminating the need for a central server - Equal Contribution: Every device in the network functions as both a client and a server - Resilience to Change: The network can adapt to changes in its participants - Elimination of Single Points of Failure: The dual role of peers as both clients and servers helps avoid single points of failure, making this architecture useful for applications that require high reliability - Resource Sharing: The network allows for the sharing of resources among peers
Pipes and Filters	Architectural pattern for stream processing. It consists of one or more components called filters	- Filters: These are components that transform or filter data. They can be seen as functions like sorting and counting - Pipes: These are connectors that pass data from one filter to another - Independent Processing: Since filters do not share state with other filters, they don’t need to know the identity of their upstream or downstream filters. In other words, filters can work independently - Change Resilience: New filters can be added to existing systems since the filters are separate from each other and connected by explicit connectors
Presentation–Abstraction–Control (PAC)	Interaction-oriented software architecture that separates an interactive system into 3 types of components	- Abstraction Component: Retrieves and processes data - Presentation Component: Formats the visual and audio presentation of data - Control Component: Handles the flow of control and communication between the other two components
Publish-Subscribe	Messaging system where publishers categorize messages into classes without knowing the subscribers. Subscribers, on the other hand, show interest in certain classes of messages and receive only those, without knowing the publishers	- Decoupling: The publishers and subscribers are independent entities, only connected through a message queue - Asynchronous communication: Messages are exchanged without requiring immediate acknowledgement, allowing tasks to continue uninterrupted - Scalability: The system can easily accommodate new publishers and subscribers without disruption - Fault tolerance: If a message isn't processed successfully, it can be retried or moved to a separate queue for handling errors
Reflection	Architectural style based on the concept of reflection, which allows a system to observe and modify its own structure and behavior	- Reification: The process of making something real, bringing something into being, or making something concrete - Structural Language: A declarative language that defines an architecture’s static skeleton - Dynamic Language: An imperative language that appears as a set of constraining rules written in a concurrent language - Behavioral and structural reflection: Involves agent computation and structure - Pre-reflective architecture: There exists a particular precognitive communication between an architectural work and the body, which shapes the overall (embodied) experience of an architectural setting
Representational State Transfer (REST)	Architectural style that uses a subset of HTTP. It is commonly used to create interactive applications that use Web services	- Stateless: Each request from client to server must contain all the information needed to understand and process the request - Client-Server: The client and server are separate entities that communicate over a network - Cacheable: Clients can cache responses to improve performance - Layered System: The architecture is composed of hierarchical layers, providing a high level of abstraction - Uniform Interface: The method of communication between the client and server is standardized
Rule-Based	Architectural style where the system’s behavior is dictated by a set of rules	- Rule Engine: The core component that interprets and executes rules - Rules: Defined in a specific format, often IF-THEN-ELSE statements - Fact Model: The data on which rules operate - Rulebase: The storage of rules - Inference Engine: Applies the rules to the known facts to deduce new facts - Working Memory: Stores the facts the system currently knows
Sensor–Controller–Actuator	Architectural pattern that helps with actuating in face of several input senses	- Sensing: This subsystem is responsible for collecting sensor data - Planning: This subsystem processes the sensor data and passes information to the controller - Execution: This subsystem, also known as the controller, sends actuator commands based on the information received from the planner - Sequential organization: These components are organized in a sequential fashion, with sensor data being passed to the planner, who then passes information to the controller, who sends actuator commands
Service-Oriented Architecture (SOA)	Design pattern that organizes the application into a collection of interconnected services	- Service contracts: Services communicate through well-defined interfaces - Service discovery: Services are registered and discovered at runtime - Service composition: Services are combined to form complex business processes
Shared Nothing Architecture (SNA)	Distributed computing architecture that consists of multiple separated nodes that don’t share resources	- Independent Nodes: Each node in the system is independent and self-sufficient with its own disk space and memory - Data Partitioning: The data set/workload is split into smaller sets (nodes) distributed into different parts of the system - High-Speed Interconnect Network: Nodes communicate and synchronize through a high-speed interconnect network - Scalability: The system supports incremental growth. New nodes can be added to scale the distributed system horizontally - No Shared Resources: Unlike other architectures, SNA has no shared resources
Space-Based Architecture (SBA)	Distributed-computing architecture for achieving linear scalability of stateful, high-performance applications	- Tuple Space Paradigm: Components interact with each other by exchanging tuples or entries via one or more shared spaces - Processing Units (PUs): Self-sufficient units that are independent of each other. Each PU encapsulates the business logic and the data it needs to perform operations - Space: A distributed, shared memory data grid where all data resides and is accessible to every processing unit - Router: Routes client requests to the appropriate processing unit - Shared Nothing System: Achieves scalability by distributing both processing and storage across multiple servers