What Are Software Architecture Styles and Why They Matter

Architecture styles are a set of principles that act as coarse‑grained patterns providing an abstract framework for families of systems, improving modularity and enabling reuse of proven solutions.

Typical questions for a software architecture style include:

What is the design vocabulary? What are the component and connector types?

What structural patterns are allowed?

What is the underlying computational model?

What are the invariants of the style?

What are common examples of its use?

What are the pros and cons of using the style?

What are typical specializations?

Using architecture styles deliberately brings several benefits:

Facilitates design reuse by providing reliable, practiced solutions for new problems.

Enables code reuse because invariant parts of a style can be shared.

Improves communication and understanding among designers.

Supports interoperability through standard styles, easing tool integration.

Allows analysis of a design space when the style is fixed.

Provides visualisation support for a given style.

Open questions that remain difficult to answer include which design points can be described by a style, how to compare styles using system characteristics, whether generic tools can extend styles, and how to select or compose styles for a particular problem.

Client‑Server Divides the system into two applications, where the client sends service requests to the server. Component‑Based Architecture Decomposes an application into reusable functional components with transparent placement, exposing only well‑defined interfaces. Layered Architecture Organises concerns into stacked layers. Message Bus A system that receives and sends messages using known formats, allowing components to communicate without knowing the actual receivers. N‑Tier / Three‑Tier Architecture Similar to layered style, it partitions functionality into independent parts (tiers) that may run on separate machines. Object‑Oriented Divides tasks into independent, reusable objects that encapsulate data and behaviour. Presentation‑Separation Separates UI logic from the data and view. Service‑Oriented Architecture (SOA) Exposes functionality as services via contracts and messages.

These styles are suited to particular domains:

Communication SOA, Message Bus, Pipe‑Filter Deployment Client/Server, Three‑Tier, N‑Tier Domain Domain Model, Gateway Interaction Presentation‑Separation Structure Component‑Based, Object‑Oriented, Layered

Pipeline and Filter Style

In a pipe‑filter architecture each component (filter) has input and output streams; it reads data, processes it, and produces output, which becomes the input of the next filter. Filters are independent, do not share data, and are unaware of upstream or downstream components. The style promotes high cohesion, low coupling, incremental processing, parallel execution, and easy addition or replacement of filters, but can lead to batch‑oriented designs, poor support for interactive applications, and added parsing overhead.

Data Abstraction and Object‑Oriented Style

Data abstraction and object‑orientation encapsulate representation and operations within abstract data types or objects. Objects act as managers, maintaining resource integrity and interacting via function or procedure calls.

Advantages include representation independence and modularisation; disadvantages involve the need to know object identifiers and potential side‑effects when objects share data.

Event‑Based Implicit Call Style

Components do not call procedures directly; instead they broadcast events. Other components register handlers for those events, and the system automatically invokes them when the event occurs. This decouples components, supports reuse, and eases substitution, but the triggering component cannot predict which components will respond, nor the order of execution.

Hierarchical System Style

Systems are organised into a hierarchy where each layer provides services to the layer above and acts as a client to the layer below. Only selected interfaces are exposed between adjacent layers, enabling abstraction, incremental development, and reuse, though not all systems fit neatly into a layered model and finding appropriate abstractions can be hard.

Repository Style

Two component types exist: a central data structure representing the current state, and independent components that operate on that data. Variants include traditional databases and blackboard systems, where the latter is used in signal processing and loosely coupled data sharing.

C2 Style

C2 defines a network of parallel components bound by connectors that obey a set of rules: each component and connector has a top and bottom; tops connect to bottoms of connectors, and direct component‑to‑component connections are prohibited. Communication is asynchronous via connectors.

Three‑Tier Client/Server

Traditional two‑tier C/S suffers from scalability, vendor lock‑in, limited integration, and management issues. The three‑tier model separates presentation, business logic, and data layers, allowing independent development, flexible hardware deployment, and improved maintainability, though communication efficiency between layers must be carefully designed.

JB/HMB (Hierarchical Message Bus) Style

The JB/HMB style combines hierarchical message buses with component‑based distribution and concurrency. Components register interest in message types on a bus; the bus dispatches, filters, and returns results. Components can be atomic or composite, forming a tree‑like topology. The style supports runtime evolution: dynamic addition/removal of components, changing message subscriptions, and message filtering.

REST Architectural Style

REST is the architectural style of the Web itself. It treats a server as a collection of addressable resources, each with representations (HTML, XML, JSON, etc.). State transfer occurs via representations, not by embedding operation semantics in the message body. A uniform interface (HTTP methods, headers, status codes, content negotiation, caching, authentication) and hypermedia‑driven navigation (HATEOAS) are mandatory. REST offers simplicity, scalability through caching, and loose coupling compared with Distributed Objects (DO) and Remote Procedure Call (RPC) styles.

Key REST characteristics: resource‑oriented, addressable, connected, stateless, uniform interface, and hypertext‑driven. Compared with DO and RPC, REST is language‑neutral, uses a uniform interface, supports hypermedia, data streams, and achieves the lowest coupling.

In summary, architecture styles provide high‑level design blueprints that influence modularity, reuse, communication, and evolution of software systems across many domains.