Software Architecture¶
Tier: 2 (Architectural Judgment)
Concepts: 14
Durability: Timeless (Principles from 1970s remain central to modern systems; concerns are inherent to organizing complex software)
Fundamental Tensions¶
| Tension | Description |
|---|---|
| Coupling vs. Flexibility | Tighter coupling enables simpler direct communication but creates rigid systems that resist change. Looser coupling enables independent evolution but adds indirection complexity. This tension cannot be eliminated because components must eventually communicate to accomplish work. |
| Simplicity vs. Capability | Simple architectures are easier to understand and maintain but may lack power for complex requirements. Sophisticated architectures handle complex needs but impose cognitive overhead. Complexity is conserved - it can be moved but not destroyed. |
| Consistency vs. Autonomy | Uniform architecture enables reasoning across the system and shared tooling, but constrains teams to common decisions. Autonomous boundaries let teams optimize locally but fragment the system. Organizations must balance coordination costs against specialization benefits. |
| Anticipation vs. YAGNI | Designing for future needs prevents costly rework but wastes effort on unused abstractions. Building only what's needed is efficient but may create expensive retrofitting. Future requirements are inherently uncertain, making perfect foresight impossible. |
| Depth vs. Breadth | Deep modules hide complexity behind simple interfaces but require understanding hidden behavior. Shallow modules expose what they do but proliferate interfaces. The underlying complexity must exist somewhere; architecture chooses where to place it. |
Concepts¶
- Information Hiding
- Coupling
- Cohesion
- Separation of Concerns
- Deep Modules
- Dependency Direction
- Architectural Boundaries
- Ports and Adapters
- Bounded Context
- Layered Architecture
- Modular Decomposition
- Abstraction
- Architecture as Decision Management
- Encapsulation
Cross-Domain Transfer Summary¶
| This Domain Concept | Transfers To |
|---|---|
| Information Hiding | API Design, Data Modeling, Security, Hardware Engineering |
| Coupling | Organizational Design, Distributed Systems, Testing, Database Design |
| Cohesion | Writing, Product Design, Organizational Design, Data Modeling |
| Separation of Concerns | Writing, Government, Manufacturing, Hardware |
| Deep Modules | API Design, Product Design, Management, System Design |
| Dependency Direction | Organizational Design, Supply Chain, Build Systems, Package Management |
| Architectural Boundaries | Political Science, Biology, Economics, Physics |
| Ports and Adapters | Hardware Design, Electronics, International Trade, Diplomacy |
| Bounded Context | Linguistics, Organizational Design, Legal Systems, Database Federation |
| Layered Architecture | Network Protocols, Operating Systems, Hardware, Bureaucracy |
| Modular Decomposition | Organizational Design, Manufacturing, Writing, Product Management |
| Abstraction | Mathematics, Science, Maps, Language |
| Architecture as Decision Management | Project Management, Strategic Planning, Legal Contracts, Personal Finance |
| Encapsulation | Biology, Organizations, Hardware, Legal Entities |
Canonical Sources¶
| Source | Coverage |
|---|---|
| Parnas, "On the Criteria for Decomposing Systems into Modules" (1972) | Information hiding, modular decomposition, volatility-based design |
| Stevens, Myers, Constantine, "Structured Design" (1974) | Coupling, cohesion, fundamental metrics for module quality |
| Dijkstra, "On the Role of Scientific Thought" (1974) | Separation of concerns as cognitive necessity |
| Dijkstra, "THE Multiprogramming System" (1968) | Layered architecture origins |
| Ousterhout, "A Philosophy of Software Design" (2018) | Deep modules, complexity management, interface design |
| Martin, "Clean Architecture" (2017) | Dependency direction, boundaries, component principles |
| Evans, "Domain-Driven Design" (2003) | Bounded contexts, ubiquitous language, strategic design |
| Cockburn, "Hexagonal Architecture" (2005) | Ports and adapters, I/O isolation |
| Bass, Clements, Kazman, "Software Architecture in Practice" (2012) | Comprehensive architecture treatment, quality attributes |
| Conway, "How Do Committees Invent?" (1968) | Organizational structure mirrors system structure |
| Liskov, "Data Abstraction and Hierarchy" (1988) | Abstraction principles, substitutability |
| Spolsky, "The Law of Leaky Abstractions" (2002) | Abstraction limitations, practical trade-offs |
| Meyer, "Object-Oriented Software Construction" (1988) | Encapsulation, design by contract |
| Buschmann et al., "Pattern-Oriented Software Architecture" (1996) | Architectural patterns, layers pattern |
| Tyree & Akerman, "Architecture Decisions: Demystifying Architecture" (2005) | Decision-centric view of architecture |