Thick Walls
pattern established
Source: Architecture and Building → Software Abstraction
Categories: systems-thinkingsoftware-engineering
Transfers
Alexander’s pattern #197 observes that traditional buildings had walls two to three feet thick — thick enough to contain window seats, storage niches, bookshelves, fireplaces, and passages. Modern construction economics drove walls thin, reducing them to four-inch partitions that do nothing but divide. The result is that the boundary between rooms becomes a dead line rather than a living zone. Alexander argues for restoring thickness to walls so that the boundary itself becomes a place where useful things happen.
Key structural parallels:
-
Boundaries as functional zones, not zero-width lines — a thin wall is a divider: it separates room A from room B and does nothing else. A thick wall is a place: it separates A from B while also containing a window seat where someone reads, a shelf where books live, a cupboard where dishes are stored. The structural insight is that the boundary between two domains can itself be a domain — not merely a line where one thing ends and another begins, but a zone with its own affordances.
In software, this maps onto the difference between a thin interface (a function signature that passes data through unchanged) and a thick interface (middleware, an API gateway, an adapter layer that transforms, validates, caches, logs, and rate-limits as data passes through). The thin interface is efficient but does nothing useful at the boundary. The thick interface makes the boundary productive.
-
Productive ambiguity — a window seat in a thick wall belongs to both the room and the outdoors simultaneously. The person sitting there is inside (sheltered, warm, private) and outside (seeing the street, feeling the light, connected to the world). This ambiguity is not a design flaw; it is the source of the seat’s value. In software, the equivalent is a boundary component that participates in both systems: an API translator that understands the internal domain model and the external contract simultaneously, a database view that belongs to both the storage layer and the query layer, a DTO that is shaped by both the sender’s constraints and the receiver’s needs.
-
Thickness is proportional to function — Alexander notes that a four-inch wall holds nothing, a twelve-inch wall holds shelves, a twenty-four-inch wall holds a seat, a thirty-six-inch wall holds a passage. The richer the boundary behavior you want, the more resources you must invest in the boundary layer. This maps onto the engineering decision about how much logic to place in middleware, adapters, and gateway layers. A REST API that does nothing but route requests is thin. An API gateway that handles authentication, rate limiting, request transformation, response caching, and circuit breaking is thick. The pattern argues that the investment should match the need: some boundaries warrant thickness, others do not.
-
Thick walls reduce furniture in rooms — when the wall contains the bookshelf, the room does not need a freestanding bookcase. When the wall contains the seat, the room does not need a chair near the window. The thick wall simplifies the rooms it separates by absorbing functionality that would otherwise clutter the interior. In software, a well-designed middleware layer absorbs cross-cutting concerns (logging, authentication, serialization) that would otherwise be duplicated inside every service. The “rooms” (services) become simpler because the “wall” (middleware) handles what they would otherwise each implement independently.
Limits
-
Software walls can grow without limit — a physical wall thicker than four feet starts consuming usable room area, providing natural feedback that the wall has become too thick. Software boundary layers have no such constraint. An API gateway can accumulate logic indefinitely — request transformation, business rules, caching policies, feature flags — until it becomes a monolith in its own right, harder to maintain than the services it was meant to connect. The pattern provides the intuition that thick boundaries are valuable but offers no mechanism for recognizing when thickness has become pathological.
-
Thick boundaries resist change — a window seat built into a two-foot masonry wall cannot be easily removed or repositioned. The more behavior embedded in a boundary layer, the more tightly coupled it becomes to the systems on either side, and the harder it is to change either system independently. In software, a middleware layer that contains business logic creates a coupling that makes refactoring the internal API or the external contract painful. Sometimes the thinnest possible boundary — a wire protocol, an interface definition — is the most maintainable precisely because it contains nothing that needs to change.
-
The pattern assumes two stable rooms — Alexander’s thick wall sits between a room and the outdoors, or between two rooms, both of which have known and stable purposes. Software boundaries often separate systems whose responsibilities are evolving. A thick adapter layer designed for today’s internal model and today’s external contract becomes a liability when either side changes, because the wall now contains stale assumptions about both rooms.
-
Thin walls enable composability — the Unix philosophy of small programs connected by pipes depends on thin boundaries: each program reads stdin and writes stdout, with no middleware logic in between. The power comes from the thinness of the pipe, which lets any program connect to any other. Thickening the pipe (adding transformation, validation, buffering) would make each connection more functional but less composable. The pattern’s preference for thickness is at odds with the compositional power of minimal interfaces.
Expressions
- “Middleware” — software layer that sits in the boundary between client and server, performing cross-cutting functions
- “API gateway” — a thick boundary that handles routing, auth, rate limiting, and transformation for downstream services
- “Adapter pattern” — design pattern that places transformation logic at the boundary between incompatible interfaces
- “The wall” — informal term for a firewall or security boundary that contains inspection and filtering logic
- “Fat interface” — pejorative term for an interface that does too much, importing the sense that walls can be too thick
- “Shim” — a thin piece inserted at a boundary to make two components fit, the opposite of a thick wall
Origin Story
Christopher Alexander’s pattern #197, “Thick Walls,” appears in A Pattern Language (1977). Alexander observed that pre-industrial buildings, from medieval castles to vernacular farmhouses, had walls thick enough to inhabit. The thickness was originally structural (load-bearing masonry requires mass), but builders discovered that the resulting depth could be used for window seats, storage, fireplaces, and even secret passages. When steel and concrete framing made thick walls structurally unnecessary, builders made them thin — and lost the rich boundary zone that traditional construction provided.
The pattern’s transfer to software architecture became visible in the middleware and API gateway debates of the 2010s. The question of how much logic to place in boundary layers — how “thick” to make the wall between services — recapitulates Alexander’s argument about the value of investing in boundaries. Eric Evans’s Domain- Driven Design (2003) introduced the “anti-corruption layer,” an explicitly thick boundary designed to protect an internal model from external pollution, which is the most direct software descendant of Alexander’s thick wall.
References
- Alexander, Christopher. A Pattern Language (1977), Pattern #197: Thick Walls
- Evans, Eric. Domain-Driven Design (2003) — anti-corruption layer as a thick boundary between bounded contexts
- Hohpe, Gregor & Woolf, Bobby. Enterprise Integration Patterns (2003) — messaging middleware as thick walls between systems
Related Entries
Structural Neighbors
Entries from different domains that share structural shape. Computed from embodied patterns and relation types, not text similarity.
- Psychological Safety (psychology/mental-model)
- Chessboard Self (puzzles-and-games/metaphor)
- Cyberspace Is a Place (spatial-location/metaphor)
- Potential Space (spatial-location/metaphor)
- Harm Is Being in a Harmful Location (spatial-location/metaphor)
- The Matrix Is Hidden Reality (science-fiction/metaphor)
- Holding Environment (containers/metaphor)
- Window (embodied-experience/metaphor)
Structural Tags
Patterns: boundarysurface-depthcontainer
Relations: containenable
Structure: boundary Level: specific
Contributors: agent:metaphorex-miner