
Concepts of Great Software Design
A Practical Approach to Clean, Scalable, and Maintainable Software ArchitecturesBy Emil VondracekLength12h 27m
About this audiobook
Software does not get hard because it is large. It gets hard because nobody can predict what will break.
Most books on software design hand you patterns and principles, then leave you to guess which one applies to the code in front of you. This book treats complexity as a measurable cost and attacks it at the design level. You will learn to identify the concept a module is really about, hide the decisions that should never leak, and judge an interface by how much work it hides rather than how many methods it exposes.
Each idea arrives with a short before-and-after and the specific change it makes cheaper. Error-handling chapters show how to define special cases out of existence instead of propagating them upward. Later chapters cover layering and dependency direction, domain modeling, APIs that survive their second version, and testing used as design feedback rather than proof. The goal is not clever code. The goal is code that stays cheap to change.
What you will learn:
• Recognize the forms of complexity that make software hard to change
• Treat concepts, not files or functions, as the unit of design
• Use abstraction, interfaces, and information hiding to contain decisions
• Evaluate module depth, coupling, and cohesion as design signals
• Write names, comments, and documentation that carry design intent
• Design it twice: compare alternatives before committing to an interface
• Define error cases out of existence and place defensive boundaries correctly
• Direct dependencies with layering and inversion of control
• Shape domain models, data, and APIs that age well across versions
• Use testing and refactoring as feedback for strategic design investment
For working developers, tech leads, and computer science students moving beyond syntax. If you can write code that runs but want to understand why some codebases stay easy to work in and others do not, this book gives you the concepts and the concrete changes to get there.
Audiobook details
GenreTechnology
Length12 hrs 27 mins
Narrated byListen with 1,000+ voices
FormateBook with Audio
Publish dateSep 27, 2026
LanguageEnglish
Table of contents
1Foreword
2Preface
3About This Book
4Chapter 1: Complexity: What Makes Software Hard to Change
51.1 Defining Complexity as Change Cost
Show all chaptersShow less
61.2 Symptoms: Change Amplification, Cognitive Load, Unknown Unknowns
71.3 Dependency and Obscurity as the Two Causes
81.4 Why Size Alone Does Not Predict Difficulty
91.5 Locating Complexity: Interfaces, Shared State, Hidden Ordering
101.6 Setting a Complexity Budget for a Team
11Chapter 2: Concepts as the Unit of Design
122.1 What a Concept Is and How to Name It
132.2 One Module, One Concept
142.3 The Cost of Conflated Concepts
152.4 Concepts at the Boundary: What Callers Should See
162.5 Splitting and Merging: When to Do Which
172.6 Concepts and the Shape of the Whole System
18Chapter 3: Abstraction, Interfaces and Information Hiding
193.1 What an Interface Promises
203.2 Information Hiding: Deciding What Must Not Leak
213.3 Leaky Abstractions and How Decisions Propagate
223.4 Separating Interface from Implementation in Practice
233.5 Abstraction Failure Modes: Too Thin, Too Fat, Wrong Axis
243.6 Choosing the Right Abstraction Boundary
25Chapter 4: Module Depth, Coupling and Cohesion
264.1 Depth: Functionality Hidden per Unit of Interface
274.2 Cohesion: One Reason to Change
284.3 Coupling: Afferent, Efferent and the Cost of Each
294.4 Shallow Wrappers and Pass-Through Methods
304.5 Premature Configurability
314.6 Measuring and Improving Depth Deliberately
32Chapter 5: Naming, Comments and Design Documentation
335.1 Names That Carry Intent
345.2 Comments That Record Why
355.3 Interface Documentation and Cross-Module Invariants
365.4 Durable Design Records
375.5 Documentation That Stays True
38Chapter 6: Designing It Twice: Alternatives Before Commitment
396.1 Why One Design Is Never Enough
406.2 Generating Two or Three Real Options
416.3 Comparing Options Against Expected Change
426.4 Deciding, Recording and Reopening
43Chapter 7: Errors, Failure Modes and Defensive Boundaries
447.1 Defining Special Cases Out of Existence
457.2 Failure Modes at Boundaries
467.3 Where Errors Should Surface
477.4 Masking, Aggregation and Partial Failure
48Chapter 8: Layering, Dependencies and Inversion of Control
498.1 Direction of Dependencies
508.2 Inverting a Stubborn Dependency