Software architecture · Level 2: Structure · Module 09 of 46

Architecture quantum and the domain

An architecture diagram shows boxes, but what decides how a system behaves is which boxes must live and die together. Two services drawn separately but sharing a database, or calling each other synchronously, behave as one unit: they scale together, fail together and must meet the same characteristics. That unit is the architecture quantum, and counting quanta honestly is how you know whether a system is really distributed, and whether it should be.

1. The idea

A row of terraced houses. From the street they look like separate homes, each with its own door. But they share walls, a roof and the water main. If the main bursts, every house floods; to replace the roof, everyone has to agree. A detached house with its own pipes can do what it likes. Two services that share a database or call each other synchronously are terraced houses, however separate they look on the diagram.

An architecture quantum is the smallest part of a system that can be deployed on its own and still work. It has three properties:

Independently deployable, together with everything it needs to run: its database, its broker, any service it can't work without.
High functional cohesion: it does one coherent job (Module 07).
Its own architecture characteristics: because it's deployed and runs on its own, it can be scaled, secured and made available on its own terms.

Two kinds of coupling decide where one quantum ends and the next begins. Static coupling is what a part needs in order to start: shared databases, shared libraries, a broker. Parts that share a database are one quantum. Dynamic coupling is how parts talk while running: a synchronous call ties the caller to the callee (it waits, so it can't be faster or more available than the callee), while an asynchronous message lets each side run at its own pace.

Why it matters: architecture characteristics apply per quantum. If one part needs elasticity and another needs strict security and auditing, and both are in one quantum, that quantum must provide both, which is expensive or impossible. A monolith with one database is one quantum, however well it's modularised inside. Different characteristics for different parts is the strongest reason to distribute.

Matching the architecture to the domain's shape

The domain has a shape of its own: some parts change together and need the same qualities; others are independent. The architecture works best when its shape matches (the two are "isomorphic").

Domain shape	Architecture that fits
Tightly connected workflows, one set of characteristics	One quantum: modular monolith or layered (Module 11)
A stable core with many customer- or region-specific variations	Microkernel: core plus plug-ins (Module 12)
A handful of coarse business areas sharing data	Service-based (Module 13)
Things that happen and many parts react	Event-driven (Module 14)
Huge, unpredictable bursts on a simple data model	Space-based (Module 15)
Many independent areas with different characteristics and teams	Microservices (Module 16)

2. How it works

Two boxes, one quantum: dynamic entanglement

A ticketing system. The Ticket service is built to be elastic. Payment runs on four certified instances that can't scale quickly. On the diagram they're two separate services. Watch what a synchronous call does during a sale.

A bounded context that's too broad

Quanta and components follow the domain's boundaries. When one model tries to mean the same thing everywhere, it couples everything that uses it. "Customer" is the classic example.

3. Try it yourself

Count the quanta

An online auction with five services. Bidding needs elasticity; Payment needs strict security and auditing. Change how the services talk and share data, and watch how many quanta you really have. Services of the same colour are one quantum.

4. Trade-offs

More quanta vs more distribution

Each extra quantum gives a part its own characteristics, deployment and team. It also adds network calls, data synchronisation and operational work. Add quanta where characteristics truly differ.

Synchronous vs asynchronous

Synchronous calls are simple and give an immediate answer, and entangle the two sides into one quantum at runtime. Asynchronous messages keep quanta independent at the cost of eventual consistency and harder error handling.

Shared vs separate data

A shared database is simple and consistent, and fuses everything that uses it into one quantum. Separate databases free each part, and make cross-part queries and transactions hard (Modules 23–24).

One model vs many

A single shared model avoids duplication but couples every context to every change. Separate models per bounded context duplicate a few fields and let each evolve alone.

5. In real projects

"Microservices" that are one quantum are common: a dozen services sharing one database, or a chain of synchronous calls where every request touches six services. They have all the costs of distribution (network, deployment pipelines, partial failures) and none of the benefits (independent scaling and characteristics).

Draw the quanta, not just the services. In a review, colour each group of services that share a database or call each other synchronously on the critical path. If there's one colour, the system is a distributed monolith.

Use the domain to decide where to split. Talk to domain experts about which parts change together, which need different characteristics, and where words mean different things. Those are the boundaries of bounded contexts, and the natural edges of quanta.

Say it in the interview

Two-sentence answers

"What's an architecture quantum?" The smallest independently deployable unit, with everything it needs to run and its own architecture characteristics. Parts that share a database or call each other synchronously are one quantum.
"Why not call Payment synchronously from Ticket?" It entangles them at runtime: Ticket can't be more elastic or available than Payment. If Ticket needs elasticity, hold the seat and send the payment request asynchronously.
"When should a system be distributed?" When different parts need different architecture characteristics, or different teams need to release independently. Otherwise one well-modularised quantum is simpler.

Red flags interviewers notice

Ten services, one database, called "microservices".
Long synchronous call chains between services that need different characteristics.
One shared "Customer" or "Product" model used by every service.

6. Remember it

Memory hook: "Shared pipes, one house"Share a database or wait on a call, and two services become one quantum.

How this hook works: what "shared pipes, one house" means

What the slogan means, phrase by phrase

"Shared pipes": Static coupling (a shared database or broker) and synchronous dynamic coupling (waiting on another service).
"one house": One architecture quantum: one set of characteristics, scaling and failing together.

Why this picture fits: terraced houses look separate from the street; only the plumbing shows they're one building. Diagrams hide coupling the same way.

The story → the concept

The houses	The architecture
Separate front doors	Separate services on the diagram
Shared water main	Shared database (static coupling)
Shared wall that holds the roof up	Synchronous call (dynamic coupling)
A detached house	An independent quantum

The trap it saves you from

Believing a system is distributed and independent because the diagram has many boxes.

7. Common mistakes

The distributed monolithServices that share a database and call each other synchronously: one quantum with network calls in the middle. All of distribution's costs, none of its benefits.

Synchronous calls across different characteristicsAn elastic service calling a fixed-capacity one waits on it. Put a queue between them, or accept they're one quantum.

One enterprise-wide modelA shared Customer or Product model makes every context change together. Share identifiers and events, not models.

Splitting what the domain joinsParts that always change together, split into separate quanta, need coordinated releases and distributed transactions. Match the domain's shape.

8. Design exercise (30 minutes)

Colour the quanta (10 min). Draw the services of a system you know. Join those that share a database or call each other synchronously on the main path. Count the groups.
Characteristics per quantum (10 min). For each group, write its top characteristics. Does any group contain parts that need conflicting ones?
One untangling (10 min). Pick one synchronous call or shared table that fuses two parts with different needs. Write how you'd separate them, and what it costs.

9. Self-check quiz

Six services share one database. How many architecture quanta?

Static coupling through the database fuses them: they can't be deployed or characterised independently.

What happens to a service that calls another synchronously on every request?

Dynamic quantum entanglement: at runtime the two behave as one quantum.

What is the strongest reason to split a system into several quanta?

Characteristics apply per quantum; one quantum must satisfy all of its parts' needs.

Sales, support and billing all use a shared Customer model. What's the better design?

Separate bounded contexts can evolve alone; the shared identifier links them.

A stable core product with dozens of customer-specific variations suggests which style?

Core plus plug-ins matches the domain's shape.

10. Go deeper

Resource	Time	Why
Software Architecture: The Hard Parts (Ford, Richards, Sadalage, Dehghani)	book	Chapter 2 defines architecture quanta, static and dynamic coupling.
Bounded Context (Martin Fowler)	10 min	Why one model per context beats one model for everything.
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)	book	Architecture quanta and choosing between monolithic and distributed styles.