Unlocking Software Architecture: Why Architectural Styles Matter and How to Choose Them

Architecture Styles

An architectural style is a set of principles that can be seen as a coarse‑grained pattern providing an abstract framework for a family of systems. Using a style improves modularity, offers reusable solutions to recurring problems, and promotes design reuse.

Typical questions when considering a software architecture style include:

What vocabulary (components and connectors) is used?

What structural patterns are allowed?

What is the basic computational model?

What invariants does the style enforce?

What are common examples?

What are the pros and cons of using the style?

What are typical special cases?

Principled use of architectural styles brings several benefits:

Facilitates design reuse by providing proven solutions.

Enables code reuse through shared invariant parts.

Improves communication among designers.

Supports interoperability via standard styles.

Allows analysis of the design space when the design space is constrained.

Provides visualisation support for specific styles.

Open questions remain, such as which design points can be described by a style, how to compare styles based on system characteristics, whether generic tools can extend styles, and how to select or combine styles for a given problem.

Client‑Server Divides the system into two applications, where the client sends service requests to the server. Component‑Based Architecture Decomposes the application into reusable functional components with transparent locations and well‑defined interfaces. Layered Architecture Organises concerns into stacked layers. Message Bus A system that receives and sends messages based on 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 reusable, self‑contained objects that encapsulate data and behaviour. Presentation Separation Separates UI logic from the data and view. Service‑Oriented Architecture (SOA) Exposes functionality as services using contracts and messages.

These styles apply to specific domains:

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

Pipe‑and‑Filter Style

Each component (filter) has inputs and outputs, reads a data stream, processes it, and produces an output stream. Filters are independent, do not share data, and are unaware of upstream/downstream identifiers. The style supports incremental processing, parallel execution, and high cohesion with low coupling, but can lead to batch‑oriented designs, is less suited for interactive applications, and may incur performance overhead due to lack of a standard data format.

Data Abstraction and Object‑Oriented Style

Data abstraction and object‑orientation encapsulate data representation and operations in abstract data types or objects. Objects act as managers, maintaining resource integrity, and interact via function or procedure calls. This style offers high encapsulation, easier changes to object representation, and modularisation, but suffers from tight coupling when object identifiers change and from side‑effects when multiple objects share the same resource.

Event‑Based Implicit Call Style

Components trigger or broadcast events instead of directly invoking procedures. Other components register handlers for those events; when an event fires, all registered handlers are invoked automatically. This decouples the event source from its listeners, supporting reuse and easier substitution, but introduces uncertainty about which components will respond, ordering of handler execution, and potential performance penalties due to message parsing.

Hierarchical System Style

Systems are organised into layers where each layer provides services to the layer above and acts as a client to the layer below. Only selected output functions are visible externally; internal layers are opaque to non‑adjacent layers. This supports incremental abstraction, reuse of layers, and clear interfaces, yet not all problems fit neatly into a hierarchy and finding appropriate abstractions can be difficult.

Repository Style

Two component types exist: a central data structure representing the current state, and independent components that operate on that data. Two subclasses arise: traditional databases (triggered by input streams) and blackboard systems (triggered by the central state). Blackboard systems consist of knowledge sources, a shared blackboard, and control logic driven by the blackboard state.

C2 Style

Components and connectors are arranged in a directed graph where each component has a top and bottom; connectors link tops to bottoms and vice versa. Direct component‑to‑component links are prohibited. The style is widely used, offering encapsulated components, asynchronous message exchange via connectors, and low inter‑component dependency.

Three‑Tier Client/Server Architecture

The traditional two‑tier C/S model suffers from scalability, vendor lock‑in, limited integration, and management difficulties. The three‑tier model separates presentation, business logic, and data layers, allowing independent development, flexible hardware deployment, and easier maintenance. However, communication efficiency between layers must be carefully designed to avoid performance bottlenecks.

C/S vs B/S Comparison

C/S (client‑server) typically runs on LANs, offers strong security control, and can handle heavy client workloads, but incurs higher maintenance costs and platform‑specific development. B/S (browser‑server) runs over the Internet, simplifies maintenance and upgrades, reduces costs, and leverages thin clients, but places more load on the server and offers weaker security controls.

REST Architectural Style

REST is the architectural style of the Web, emphasizing resources identified by URIs, representations in various media types, stateless interactions, a uniform interface (HTTP methods, headers, status codes, content negotiation, caching, authentication), and hypermedia‑driven state transitions (HATEOAS). Compared with Distributed Objects (DO) and Remote Procedure Call (RPC), REST provides language‑independent resource abstraction, a uniform interface, hypermedia links, support for data streams, and the lowest coupling.

In summary, architectural styles are high‑level design choices that shape system structure, communication, and evolution. Selecting an appropriate style—or combining several—depends on domain requirements, scalability, maintainability, and interoperability goals.