Building Complex
pattern established
Source: Architecture and Building → Software Abstraction
Categories: software-engineeringsystems-thinking
From: A Pattern Language
Transfers
Alexander’s pattern #95, “Building Complex,” argues that any building program which can be implemented as a cluster of smaller buildings should be, rather than being collected under a single roof. A university should be a village of pavilions, not a megastructure. A hospital should be a campus, not a block. The monolith, Alexander observes, deadens both the people inside and the public space around it. Mapped to software, this is the structural argument against monolithic systems — not the microservices marketing pitch, but the deeper architectural claim that decomposition into semi-independent units produces systems that are easier to understand, maintain, and evolve.
Key structural parallels:
- Independent failure domains — when a building in a complex develops structural problems, the adjacent buildings stand on their own foundations and continue to function. A monolithic building with a compromised load-bearing wall threatens the entire structure. In software, a service that crashes in a decomposed system takes down its own function; a module that fails in a monolith can cascade through shared memory, shared state, and shared process boundaries. The pattern frames fault isolation as a spatial property: separate foundations mean separate fates.
- Human-scale comprehensibility — Alexander observes that people cannot form a mental model of a building beyond a certain size. A complex of smaller buildings is legible because each building can be understood individually, and the relationships between them can be grasped from the paths that connect them. This maps directly to cognitive load in software: a codebase decomposed into bounded services or modules is navigable because each piece fits in a developer’s working memory, and the interfaces between them are explicit.
- Incremental construction and replacement — a building complex can be constructed one building at a time, occupied as each is completed, and renovated building-by-building over decades. A monolith must be substantially complete before it is useful and substantially rewritten when it is obsolete. The pattern frames the strangler fig migration strategy in spatial terms: build the new building next to the old one, move people over, then demolish.
- The space between buildings is itself designed — in a complex, the courtyards, walkways, and plazas between buildings are not leftover space but designed environments. This maps to API design: the interfaces between services are not afterthoughts but first-class architectural decisions. The pattern insists that decomposition is only valuable if the connections are as carefully designed as the components.
- Each building expresses its function — a library looks different from a gymnasium because their interior requirements shape their exterior forms. In a monolith, every function hides behind the same facade. The pattern argues that decomposition enables legibility: when each component has its own boundary, its external interface can reflect its internal purpose.
Limits
- Not all systems benefit from decomposition — Alexander’s pattern acknowledges that some functions require large, unified spaces. A concert hall cannot be split into a complex of smaller rooms. In software, some workloads (real-time trading engines, in-memory databases, tight computational loops) require shared memory and minimal latency that decomposition into separate processes would destroy. The pattern’s anti-monolith stance becomes dogma when applied to inherently unified workloads.
- Complexes introduce coordination costs that monoliths avoid — a building complex requires shared infrastructure planning: roads, utilities, signage, fire access routes. A single building handles these internally. In software, microservices require service discovery, distributed tracing, API versioning, and network reliability engineering that a monolith simply does not need. The pattern frames decomposition as liberation but does not account for the governance overhead it introduces.
- The pattern romanticizes the village and demonizes the block — Alexander’s preference for campus layouts over megastructures reflects a specific aesthetic and social philosophy, not a universal engineering truth. Some monolithic buildings (Grand Central Terminal, the Hagia Sophia) are profoundly successful precisely because they unify many functions under one roof. The software equivalent — a well-structured monolith with clean internal boundaries — can be more effective than a poorly coordinated microservice mesh.
- Decomposition can be premature — Alexander’s pattern applies to mature building programs with known requirements. Splitting a system into separate services before the domain boundaries are understood produces a distributed monolith — the worst of both worlds. The pattern provides no guidance on when to decompose, only an argument that decomposition is desirable.
- Physical buildings cannot merge; software services can — the pattern draws on the irreversibility of physical construction. Once buildings are separate, combining them is a major renovation. Software services can be merged, split, and recombined with relative ease. The permanence that makes Alexander’s argument urgent in architecture does not apply with the same force in software, where the cost of getting the decomposition wrong is recoverable.
Expressions
- “Microservices architecture” — the software industry’s most direct adoption of the building-complex pattern, decomposing monoliths into independently deployable services
- “Bounded context” — domain-driven design’s term for each “building” in the complex, a self-contained unit with its own model
- “Strangler fig pattern” — incremental replacement of a monolith by building new services alongside it, then routing traffic away from the old system
- “Monolith-first” — the counter-pattern: start with a single building and decompose only when you understand the domain well enough to draw good boundaries
- “Blast radius” — the failure domain of a single service, framed as the area damaged when one building in the complex collapses
- “Cell-based architecture” — AWS’s term for decomposing infrastructure into independent units, each a building in the complex
Origin Story
Pattern #95 in A Pattern Language (1977) reflects Alexander’s observation that the largest and most enduring built environments — medieval universities, traditional hospital complexes, monastery campuses — are clusters of distinct buildings connected by outdoor space, not monolithic blocks. The pattern emerged from his study of how institutional buildings grow over time: organizations that start in one building inevitably outgrow it, and the choice between adding wings to a monolith versus constructing new adjacent buildings shapes the institution’s character for decades.
The pattern’s resonance in software engineering is direct. The Gang of Four’s Design Patterns (1994) drew explicitly on Alexander’s work, and the subsequent microservices movement (circa 2011-2014) essentially rediscovered pattern #95 for distributed systems. Martin Fowler and James Lewis’s influential 2014 article on microservices describes almost exactly the building-complex principle: small, independently deployable services organized around business capabilities, connected by lightweight protocols. The difference is that Alexander would insist the spaces between the buildings — the APIs, the contracts, the shared protocols — matter as much as the buildings themselves.
References
- Alexander, Christopher. A Pattern Language (1977), Pattern #95: Building Complex
- Fowler, Martin and Lewis, James. “Microservices” (2014) — the canonical description of decomposed service architecture
- Evans, Eric. Domain-Driven Design (2003) — bounded contexts as the decomposition principle
- Newman, Sam. Building Microservices (2015) — practical guidance on implementing the building-complex pattern in software
Related Entries
Structural Neighbors
Entries from different domains that share structural shape. Computed from embodied patterns and relation types, not text similarity.
- Chef de Partie (food-and-cooking/metaphor)
- Brigade System (food-and-cooking/paradigm)
- God Object (religion/metaphor)
- Microservices Are Biological Cells (biology/metaphor)
- Gas Town (governance/archetype)
- Filesystem Mount (tool-use/metaphor)
- DNS Domain (governance/metaphor)
- Incident Command System (fire-safety/paradigm)
Structural Tags
Patterns: part-wholeboundarylink
Relations: decomposecontaincoordinate
Structure: hierarchynetwork Level: specific
Contributors: agent:metaphorex-miner, fshot