Architecture Quantum: Defining the Scope of Architectural Characteristics in Distributed Systems

1. The Overlooked Problem

When discussing architectural characteristics, we typically assume they apply system-wide. Discussing scalability implies the entire system must scale; discussing security implies a single policy for all modules. This premise barely holds in monolithic architectures but breaks down in microservices and event-driven architectures.

Consider an online auction system: the public bidding module must handle burst traffic, demanding scalability and elasticity, while the back-office settlement module prioritizes security and data integrity. Forcing one set of architectural characteristics onto the whole system leads to either over-engineering or under-engineering critical parts.

To describe the scope of architectural characteristics, industry pioneers coined the term architecture quantum .

2. Types of Coupling

Before defining architecture quantum, we must understand coupling.

2.1 Semantic Coupling

Semantic coupling describes coupling that exists naturally in the problem domain. It stems from the business problem itself, not technical choices. Concepts like inventory, catalog, cart, customer, and sales inherently depend on each other because business processes require them to collaborate. When the domain changes, system requirements must follow; architects have almost no means to prevent domain changes from rippling through the entire system.

2.2 Implementation Coupling

Implementation coupling describes how architects and teams decide to implement specific dependencies. The same business problem can yield drastically different coupling structures depending on implementation choices, profoundly affecting deployment, data partitioning, and monolithic vs. distributed architectural decisions. Implementation coupling is the only type architects can directly control — they cannot change business semantics, but they can choose how to implement them.

2.3 Static Coupling

Static coupling refers to the architecture's "connection style" — how services depend on each other. If two services depend on the same coupling point, they belong to the same architecture quantum. For example, if Catalog and Shipping microservices both depend on a shared Address component, they form static coupling through that shared dependency and belong to the same architecture quantum.

2.4 Dynamic Coupling

Dynamic coupling describes the forces at play when architecture quanta must communicate. The most critical factor is communication style:

• Synchronous communication: two quanta are tightly coupled, effectively merging into one quantum

• Asynchronous communication: two quanta are loosely coupled, remaining independent

3. Architecture Quantum Definition

Architecture quantum defines the scope for a set of architectural characteristics. It has the following properties:

• Independently deployable

• High functional cohesion

• Low external implementation static coupling

• Synchronous communication

Independent deployability means an architecture quantum contains all components needed to run (services, databases, etc.) without depending on other parts. Without independent deployment, characteristics cannot be governed independently.

High functional cohesion means code within a quantum shares a unified goal, corresponding to a bounded context in domain-driven design. Poor cohesion implies unclear boundaries, preventing characteristics from being properly assigned.

Static implementation coupling between architecture quanta should be low, reflecting the DDD principle of low coupling between bounded contexts.

4. Practical Significance of Architecture Quantum

Identifying quantum boundaries in the problem domain helps select an architectural style :

• If the system needs only one set of architectural characteristics, choose a monolithic architecture.

• If different parts of the system need different architectural characteristics, choose a distributed architecture.

If a distributed architecture is chosen, the next step is to determine its quantum boundaries , followed by selecting persistence mechanisms. 1. Fundamentals of Software Architecture 2nd Chapter 7 ↩︎