Skip to content
Software Architecture Guide

Architecture Style

Explanation

Section titled “Explanation”

An architecture style limits your design choices on purpose. It says which kinds of elements can appear in a system. It also says how those elements may relate to each other. A design that follows these limits gets certain desirable properties.

Microservices as a style. This style constrains each service to a single responsibility. Services stay independent. Each service keeps its data private, and services do not share data. These constraints produce independent deployment, fault isolation, frequent updates and an easier path to new technology.

N-tier as a style. This style separates logical layers from physical tiers. Layers follow a dependency rule: a higher layer uses a lower one. Tiers are physically separate and run on separate machines. Layers do not have to map one-to-one onto tiers. Tiers can talk directly or through asynchronous messaging, where the sender does not wait for a reply.

Event-driven as a style. Producers and consumers stay decoupled. They communicate through event channels or brokers.

Layering rules are style constraints too. A closed layer limits the dependencies between layers. An open layer relaxes that limit.

How to choose a style. Start from the problem, not the style. Define the key business drivers. Name the matching architecture characteristics, also called nonfunctional requirements. Prioritize them, and ask stakeholders for input. Keep validating the choice, because changing a style later is costly.

Martin Fowler’s point is that a style, like any other, has both costs and benefits.

Example

Section titled “Example”

A team builds an online shop. Their top priorities are frequent releases and isolating failures. They pick microservices. Orders, payments and catalog become separate services, and each owns its own data. The payments service can be released without touching the catalog. If it fails, the catalog can keep running. In return, the team must handle communication between services and keep data consistent across them.

Trade-offs

Section titled “Trade-offs”

Every style trades benefits for costs.

  • Microservices give team autonomy and release velocity. They add complexity in service discovery, data consistency and distributed operations. They need mature DevOps practices, so they suit organizations with advanced technical capabilities.
  • Event-driven designs give scalability and fault isolation. They raise challenges with delivery, ordering and eventual consistency.
  • Physical tiers improve scalability and resiliency. They add network latency.
  • Closed layers limit dependencies. They can cause needless network traffic when a layer only passes requests along.
  • Splitting into services can increase communication overhead, which may lead to latency or network congestion.
  • Fit to the domain matters. If the style is too simple for the domain, the system can become a big ball of mud. Manageability is also a challenge.

Two logical layers deployed as separate physical tiers. A higher layer uses only the layer below it.

Diagram source 
flowchart TD
  subgraph T1[Tier 1: web server]
    P[Presentation layer]
  end
  subgraph T2[Tier 2: application server]
    B[Business layer]
  end
  subgraph T3[Tier 3: database server]
    D[Data layer]
  end
  P --> B
  B --> D

Checks

Section titled “Checks”
  • The document names the chosen architecture style and states the constraints it imposes on elements and their relationships.
  • The style choice is traced to business drivers and prioritized architecture characteristics, with stakeholder input.
  • The costs of the chosen style are stated next to its benefits, such as operational complexity or network latency.
  • If layers and physical tiers are used, the document shows how layers map to tiers and whether layers are open or closed.
  • The document says how the style choice will be validated over time, since changing it later is costly.
Section titled “Related”

Sources

Section titled “Sources”