A Pattern Language¶
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., & Angel, S. (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press.
Cited by¶
8 citations across 7 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Design Patterns
- The pattern format—which names the pattern, describes problem and context, specifies solution structure, enumerates consequences and trade-offs, and provides documented uses—originates in Christopher Alexander's architectural pattern-language work (Alexander, 1977), achieved canonical formalization through Gamma, Helm, Johnson, and Vlissides' Design Patterns in software engineering (Gamma et al., 1994), and has since generalized across domains including software architecture, urban planning, user-interface design, pedagogy, organizational design, game design, and security engineering.
This sourceOriginates the 'pattern language' methodology in architecture (253 patterns in a consistent name/problem/context/solution/discussion format); the source from which software design patterns adopted their structure.
Supported in partVerified against the work's full text
The publisher's description of Alexander's 1977 book shows named patterns each carrying a problem statement, discussion and solution, supporting the format's origin but not its later software-era elements.
“More than 250 of the patterns in this pattern language are given: each consists of a problem statement, a discussion of the problem with an illustration, and a solution.”
- From this software foundation, pattern thinking generalized: Fowler's (2002) enterprise application patterns (Repository, Service Layer, Unit of Work, Active Record, Data Mapper), cloud-infrastructure patterns (Sidecar, Ambassador, Blue-Green Deployment, Canary Release), distributed-systems patterns (Circuit Breaker, Bulkhead, Saga, CQRS, Event Sourcing) catalogued in Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996), security-architecture patterns (Defense in Depth, Zero Trust, Threat Modeling), instructional-design patterns, organizational-change patterns (Fearless Change), domain-driven design patterns (Evans, 2003), and game-design patterns all follow Alexander's documented-solution template.
This sourceCanonical catalog of 253 patterns at scales from regional planning to construction detail, in consistent format (name, rating, problem, context, solution, diagram, discussion, related patterns).
Supported in partVerified against the work's full text
Confirms A Pattern Language supplies documented problem/solution patterns, but the catalogue blurb says nothing about the later software, cloud, security or DDD families.
“More than 250 of the patterns in this pattern language are given: each consists of a problem statement, a discussion of the problem with an illustration, and a solution.”
- The pattern format—which names the pattern, describes problem and context, specifies solution structure, enumerates consequences and trade-offs, and provides documented uses—originates in Christopher Alexander's architectural pattern-language work (Alexander, 1977), achieved canonical formalization through Gamma, Helm, Johnson, and Vlissides' Design Patterns in software engineering (Gamma et al., 1994), and has since generalized across domains including software architecture, urban planning, user-interface design, pedagogy, organizational design, game design, and security engineering.
- Interface
- These patterns, originated in software but tracing their methodological lineage to Alexander's (1977) architectural pattern language, prove useful in organizational design, mechanical systems, and biological engineering.
This sourceOriginates the "pattern language" methodology in architecture; the source from which software design patterns adopted their structure, demonstrating cross-domain transferability of interface-mediated design reasoning.
Supported in partVerified against the work's full text
The cited page is a publisher catalogue blurb for Alexander's 1977 book; it confirms the architectural pattern language but supports nothing about software or other domains.
“More than 250 of the patterns in this pattern language are given: each consists of a problem statement, a discussion of the problem with an illustration, and a solution.”
- These patterns, originated in software but tracing their methodological lineage to Alexander's (1977) architectural pattern language, prove useful in organizational design, mechanical systems, and biological engineering.
- Pattern (in Design)
- Pattern originated in textile arts (weaving, dyeing, embroidery) and architectural ornament but has evolved into a foundational principle across visual design (graphic design, illustration, material design), spatial design (architecture, landscape, urban design), software engineering (design patterns for code reusability), interaction design (UI component patterns), and information visualization (pattern recognition in data)
This sourceOriginates the "pattern language" methodology in architecture; the source from which software design patterns adopted their structure, demonstrating cross-domain transferability of interface-mediated design reasoning.
Supported in partVerified against the work's full text
A 1977 architecture book presenting patterns as reusable answers to recurring design problems; it backs the architecture limb only, not the textile origin or the other listed domains.
“This book provides a language of this kind. It will enable a person to make a design for almost any kind of building, or any part of the built environment. "Patterns," the units of this language, are answers to design problems (How high should a window sill be? How many stories should a building have? How much space in a neighborhood should be devoted to grass and trees?).”
- Pattern originated in textile arts (weaving, dyeing, embroidery) and architectural ornament but has evolved into a foundational principle across visual design (graphic design, illustration, material design), spatial design (architecture, landscape, urban design), software engineering (design patterns for code reusability), interaction design (UI component patterns), and information visualization (pattern recognition in data)
Mechanisms¶
- Design Principle Card
- The useful anchor is Christopher Alexander's pattern format, which pairs each principle with the context in which it applies and the forces it resolves
This sourceUses a pattern format that states the context, recurring problem, interacting forces, and core solution for each design pattern.
- The useful anchor is Christopher Alexander's pattern format, which pairs each principle with the context in which it applies and the forces it resolves
- Emergent Practice Repository
- In effect it is a pattern language for one practice — many context-bearing variants instead of a single universal rule
This sourcePresents a collection of reusable patterns whose application depends on context rather than one universal design rule.
- In effect it is a pattern language for one practice — many context-bearing variants instead of a single universal rule
- Pattern Library
- A city's urban-design office keeps a pattern library in the spirit of Christopher Alexander's A Pattern Language
This sourcePresents a reusable collection of recurring design patterns for towns, buildings, and construction.
- A city's urban-design office keeps a pattern library in the spirit of Christopher Alexander's A Pattern Language
- Primitive Grammar Style Guide
- A well-made guide functions like a pattern language: a finite grammar from which valid wholes are generated, not a gallery of finished pieces.
This sourceDefines a pattern language as a finite connected system of reusable patterns that can generate coherent wholes rather than prescribe a gallery of fixed finished designs.
- A well-made guide functions like a pattern language: a finite grammar from which valid wholes are generated, not a gallery of finished pieces.
Verification¶
Does it exist? Confirmed. This work's ISBN resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 4 of 8 citations: 4 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 3 other ways.
- https://books.google.com/books/about/A_Pattern_Language.html?id=hwAHmktpk5IC ×2
- https://www.oup.com.au/books/general-interest/art-technology/9780195019193 ×1
- https://www.patternlanguage.com/index.html ×1
Registry ID ref:6962d72638cf · see in the full table