Fundamentals of Software Architecture
Main Argument
Software architecture has no universal best practices, only tradeoffs in context. An architect's job is to identify the architecture characteristics (the "-ilities") that matter for a given system, choose a structure that best supports the most important ones, knowing every choice sacrifices others, and keep the architecture able to evolve as understanding changes. Architecture is continuous and iterative; the rationale ("why") matters more than the mechanism ("how"); and coupling, cohesion, and team structure largely determine how a system can change.
Key Takeaways
- First Law of Software Architecture: everything is a tradeoff; if you think you have found one that isn't, you just haven't spotted it yet.
- Second Law: why is more important than how, so capture decisions and their rationale.
- An architecture is defined by the architecture characteristics it must support, and you cannot maximize them all, so you prioritize a critical few.
- Coupling and cohesion determine changeability; connascence gives a finer vocabulary for the kinds and strength of coupling.
- Architectures should be evolutionary: defer decisions to the last responsible moment and guard characteristics with fitness functions.
- Conway's Law couples organization structure and architecture, so design teams accordingly.