Software Architecture and Design Patterns

Software architecture is the discipline of making the decisions that are most expensive to change. It decides whether a team can release a feature in an afternoon or must coordinate a quarter-long project, whether a system survives the failure of a data centre or goes dark with it, and whether a newcomer can understand the code in a week or needs a year. Design patterns and design principles are the small-scale counterpart: they decide whether the code inside those structures welcomes change or resists it. This book treats the two as a single subject, because every large structure is built from small decisions, and every small decision is constrained by the large structure around it.
The book grew out of a simple observation made repeatedly in teaching: students and practitioners often know many fragments, such as the SOLID acronym, the names of the Gang of Four patterns, the word "microservices", and the CAP theorem, but lack the thread that connects them. Why does the Dependency Inversion Principle appear in the Hexagonal Architecture? Why is a Saga needed when a database is split? Why do patterns such as Strategy become one-line lambdas in modern languages, while the problem they solve does not disappear? This book tries to supply that thread. It starts from quality attributes and the economics of change (Part I), develops the design principles that keep code changeable (Part II), presents the catalogue of classical design patterns (Part III), moves up to architectural styles, Clean Architecture, and Domain-Driven Design (Part IV), and finishes with the distributed, scalable, resilient, and cloud-native systems that dominate practice today (Part V).
Approach
Three commitments shaped the writing.

• Forces before solutions. Every pattern, principle, and style is presented as an answer to a problem with competing forces, together with its consequences and the situations in which it is the wrong answer. A technique presented without its costs is advertising, not engineering.
• Precision with sources. Claims about origins, definitions, and numbers are tied to primary or authoritative sources, which are listed in the References. Where the literature disagrees or a figure is only an order of magnitude, the text says so.
• Drawing and code as first-class explanation. The book contains more than a hundred diagrams, drawn specifically for this work, and compact Java listings that show the structure of each idea. UML diagrams follow the conventions of Chapter 3; code is deliberately short and omits incidental detail so that the structure remains visible.