Robert C. Martin (“Uncle Bob”) has been a programmer since 1970. He is founder of Uncle Bob Consulting, LLC, and cofounder with his son Micah Martin of The Clean Coders LLC. Martin has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He has authored and edited many books, including: Designing Object Oriented C++ Applications Using the Booch Method, Patterns Languages of Program Design 3, More C++ Gems, Extreme Programming in Practice, Agile Software Development: Principles, Patterns, and Practices, UML for Java Programmers, Clean Code, and The Clean Coder. A leader in the industry of software development, Martin served for three years as editor-in-chief of the C++ Report, and he served as the first chairman of the Agile Alliance.

Select Guide Rating

• Foreword xvPreface xixAcknowledgments xxiiiAbout the Author xxv   Part I: Introduction 1  Chapter 1: What Is Design and Architecture? 3 The Goal? 4Case Study 5Conclusion 12  Chapter 2: A Tale of Two Values 13Behavior 14Architecture 14The Greater Value 15Eisenhower’s Matrix 16Fight for the Architecture 18   Part II: Starting with the Bricks: Programming Paradigms 19  Chapter 3: Paradigm Overview 21 Structured Programming 22Object-Oriented Programming 22Functional Programming 22Food for Thought 23Conclusion 24  Chapter 4: Structured Programming 25Proof 27A Harmful Proclamation 28Functional Decomposition 29No Formal Proofs 30Science to the Rescue 30Tests 31Conclusion 31  Chapter 5: Object-Oriented Programming 33Encapsulation? 34Inheritance? 37Polymorphism? 40Conclusion 47  Chapter 6: Functional Programming 49Squares of Integers 50Immutability and Architecture 52Segregation of Mutability 52Event Sourcing 54Conclusion 56   Part III: Design Principles 57  Chapter 7: SRP: The Single Responsibility Principle 61 Symptom 1: Accidental Duplication 63Symptom 2: Merges 65Solutions 66Conclusion 67  Chapter 8: OCP: The Open-Closed Principle 69A Thought Experiment 70Directional Control 74Information Hiding 74Conclusion 75  Chapter 9: LSP: The Liskov Substitution Principle 77Guiding the Use of Inheritance 78The Square/Rectangle Problem 79LSP and Architecture 80Example LSP Violation 80Conclusion 82  Chapter 10: ISP: The Interface Segregation Principle 83ISP and Language 85ISP and Architecture 86Conclusion 86  Chapter 11: DIP: The Dependency Inversion Principle 87Stable Abstractions 88Factories 89Concrete Components 91Conclusion 91   Part IV: Component Principles 93  Chapter 12: Components 95 A Brief History of Components 96Relocatability 99Linkers 100Conclusion 102  Chapter 13: Component Cohesion 103The Reuse/Release Equivalence Principle 104The Common Closure Principle 105The Common Reuse Principle 107The Tension Diagram for Component Cohesion 108Conclusion 110  Chapter 14: Component Coupling 111The Acyclic Dependencies Principle 112Top-Down Design 118The Stable Dependencies Principle 120The Stable Abstractions Principle 126Conclusion 132   Part V: Architecture 133  Chapter 15: What Is Architecture? 135 Development 137Deployment 138Operation 138Maintenance 139Keeping Options Open 140Device Independence 142Junk Mail 144Physical Addressing 145Conclusion 146  Chapter 16: Independence 147Use Cases 148Operation 149Development 149Deployment 150Leaving Options Open 150Decoupling Layers 151Decoupling Use Cases 152Decoupling Mode 153Independent Develop-ability 153Independent Deployability 154Duplication 154Decoupling Modes (Again) 155Conclusion 158  Chapter 17: Boundaries: Drawing Lines 159A Couple of Sad Stories 160FitNesse 163Which Lines Do You Draw, and When Do You Draw Them? 165What About Input and Output? 169Plugin Architecture 170The Plugin Argument 172Conclusion 173  Chapter 18: Boundary Anatomy 175Boundary Crossing 176The Dreaded Monolith 176Deployment Components 178Threads 179Local Processes 179Services 180Conclusion 181  Chapter 19: Policy and Level 183Level 184Conclusion 187  Chapter 20: Business Rules 189Entities 190Use Cases 191Request and Response Models 193Conclusion 194  Chapter 21: Screaming Architecture 195The Theme of an Architecture 196The Purpose of an Architecture 197But What About the Web? 197Frameworks Are Tools, Not Ways of Life 198Testable Architectures 198Conclusion 199  Chapter 22: The Clean Architecture 201The Dependency Rule 203A Typical Scenario 207Conclusion 209  Chapter 23: Presenters and Humble Objects 211The Humble Object Pattern 212Presenters and Views 212Testing and Architecture 213Database Gateways 214Data Mappers 214Service Listeners 215Conclusion 215  Chapter 24: Partial Boundaries 217Skip the Last Step 218One-Dimensional Boundaries 219Facades 220Conclusion 220  Chapter 25: Layers and Boundaries 221Hunt the Wumpus 222Clean Architecture? 223Crossing the Streams 226Splitting the Streams 227Conclusion 228  Chapter 26: The Main Component 231The Ultimate Detail 232Conclusion 237  Chapter 27: Services: Great and Small 239Service Architecture? 240Service Benefits? 240The Kitty Problem 242Objects to the Rescue 244Component-Based Services 245Cross-Cutting Concerns 246Conclusion 247  Chapter 28: The Test Boundary 249Tests as System Components 250Design for Testability 251The Testing API 252Conclusion 253  Chapter 29: Clean Embedded Architecture 255App-titude Test 258The Target-Hardware Bottleneck 261Conclusion 273   Part VI: Details 275  Chapter 30: The Database Is a Detail 277 Relational Databases 278Why Are Database Systems So Prevalent? 279What If There Were No Disk? 280Details 281But What about Performance? 281Anecdote 281Conclusion 283  Chapter 31: The Web Is a Detail 285The Endless Pendulum 286The Upshot 288Conclusion 289  Chapter 32: Frameworks Are Details 291Framework Authors 292Asymmetric Marriage 292The Risks 293The Solution 294I Now Pronounce You … 295Conclusion 295  Chapter 33: Case Study: Video Sales 297The Product 298Use Case Analysis 298Component Architecture 300Dependency Management 302Conclusion 302  Chapter 34: The Missing Chapter 303Package by Layer 304Package by Feature 306Ports and Adapters 308Package by Component 310The Devil Is in the Implementation Details 315Organization versus Encapsulation 316Other Decoupling Modes 319Conclusion: The Missing Advice 321   Part VII: Appendix 323Appendix A Architecture Archaeology 325  Index 375

1. 5/5

   Important guidelines.

   The book describes how to use a plug-in architecture to create a clean and robust system design. It is a complement to books like "Effective Java" by Joshua Bloch in being more of an introduction to the discussions in Blochs book (which is very good). That is being an introduction to design of systems, using building blocks like classes/interfaces and reusable components. I found part three "Design principles" ( SOLID) and part four "Component principles" very useful. The book summarizes the discussions with a comprehensive Use case analysis in chapter 33. This is not a book for beginners, though.

   Tom V

   30 september 2018

Robert C. Martin (“Uncle Bob”) has been a programmer since 1970. He is founder of Uncle Bob Consulting, LLC, and cofounder with his son Micah Martin of The Clean Coders LLC. Martin has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He has authored and edited many books, including: Designing Object Oriented C++ Applications Using the Booch Method, Patterns Languages of Program Design 3, More C++ Gems, Extreme Programming in Practice, Agile Software Development: Principles, Patterns, and Practices, UML for Java Programmers, Clean Code, and The Clean Coder. A leader in the industry of software development, Martin served for three years as editor-in-chief of the C++ Report, and he served as the first chairman of the Agile Alliance.

Select Guide Rating

• Foreword xvPreface xixAcknowledgments xxiiiAbout the Author xxv   Part I: Introduction 1  Chapter 1: What Is Design and Architecture? 3 The Goal? 4Case Study 5Conclusion 12  Chapter 2: A Tale of Two Values 13Behavior 14Architecture 14The Greater Value 15Eisenhower’s Matrix 16Fight for the Architecture 18   Part II: Starting with the Bricks: Programming Paradigms 19  Chapter 3: Paradigm Overview 21 Structured Programming 22Object-Oriented Programming 22Functional Programming 22Food for Thought 23Conclusion 24  Chapter 4: Structured Programming 25Proof 27A Harmful Proclamation 28Functional Decomposition 29No Formal Proofs 30Science to the Rescue 30Tests 31Conclusion 31  Chapter 5: Object-Oriented Programming 33Encapsulation? 34Inheritance? 37Polymorphism? 40Conclusion 47  Chapter 6: Functional Programming 49Squares of Integers 50Immutability and Architecture 52Segregation of Mutability 52Event Sourcing 54Conclusion 56   Part III: Design Principles 57  Chapter 7: SRP: The Single Responsibility Principle 61 Symptom 1: Accidental Duplication 63Symptom 2: Merges 65Solutions 66Conclusion 67  Chapter 8: OCP: The Open-Closed Principle 69A Thought Experiment 70Directional Control 74Information Hiding 74Conclusion 75  Chapter 9: LSP: The Liskov Substitution Principle 77Guiding the Use of Inheritance 78The Square/Rectangle Problem 79LSP and Architecture 80Example LSP Violation 80Conclusion 82  Chapter 10: ISP: The Interface Segregation Principle 83ISP and Language 85ISP and Architecture 86Conclusion 86  Chapter 11: DIP: The Dependency Inversion Principle 87Stable Abstractions 88Factories 89Concrete Components 91Conclusion 91   Part IV: Component Principles 93  Chapter 12: Components 95 A Brief History of Components 96Relocatability 99Linkers 100Conclusion 102  Chapter 13: Component Cohesion 103The Reuse/Release Equivalence Principle 104The Common Closure Principle 105The Common Reuse Principle 107The Tension Diagram for Component Cohesion 108Conclusion 110  Chapter 14: Component Coupling 111The Acyclic Dependencies Principle 112Top-Down Design 118The Stable Dependencies Principle 120The Stable Abstractions Principle 126Conclusion 132   Part V: Architecture 133  Chapter 15: What Is Architecture? 135 Development 137Deployment 138Operation 138Maintenance 139Keeping Options Open 140Device Independence 142Junk Mail 144Physical Addressing 145Conclusion 146  Chapter 16: Independence 147Use Cases 148Operation 149Development 149Deployment 150Leaving Options Open 150Decoupling Layers 151Decoupling Use Cases 152Decoupling Mode 153Independent Develop-ability 153Independent Deployability 154Duplication 154Decoupling Modes (Again) 155Conclusion 158  Chapter 17: Boundaries: Drawing Lines 159A Couple of Sad Stories 160FitNesse 163Which Lines Do You Draw, and When Do You Draw Them? 165What About Input and Output? 169Plugin Architecture 170The Plugin Argument 172Conclusion 173  Chapter 18: Boundary Anatomy 175Boundary Crossing 176The Dreaded Monolith 176Deployment Components 178Threads 179Local Processes 179Services 180Conclusion 181  Chapter 19: Policy and Level 183Level 184Conclusion 187  Chapter 20: Business Rules 189Entities 190Use Cases 191Request and Response Models 193Conclusion 194  Chapter 21: Screaming Architecture 195The Theme of an Architecture 196The Purpose of an Architecture 197But What About the Web? 197Frameworks Are Tools, Not Ways of Life 198Testable Architectures 198Conclusion 199  Chapter 22: The Clean Architecture 201The Dependency Rule 203A Typical Scenario 207Conclusion 209  Chapter 23: Presenters and Humble Objects 211The Humble Object Pattern 212Presenters and Views 212Testing and Architecture 213Database Gateways 214Data Mappers 214Service Listeners 215Conclusion 215  Chapter 24: Partial Boundaries 217Skip the Last Step 218One-Dimensional Boundaries 219Facades 220Conclusion 220  Chapter 25: Layers and Boundaries 221Hunt the Wumpus 222Clean Architecture? 223Crossing the Streams 226Splitting the Streams 227Conclusion 228  Chapter 26: The Main Component 231The Ultimate Detail 232Conclusion 237  Chapter 27: Services: Great and Small 239Service Architecture? 240Service Benefits? 240The Kitty Problem 242Objects to the Rescue 244Component-Based Services 245Cross-Cutting Concerns 246Conclusion 247  Chapter 28: The Test Boundary 249Tests as System Components 250Design for Testability 251The Testing API 252Conclusion 253  Chapter 29: Clean Embedded Architecture 255App-titude Test 258The Target-Hardware Bottleneck 261Conclusion 273   Part VI: Details 275  Chapter 30: The Database Is a Detail 277 Relational Databases 278Why Are Database Systems So Prevalent? 279What If There Were No Disk? 280Details 281But What about Performance? 281Anecdote 281Conclusion 283  Chapter 31: The Web Is a Detail 285The Endless Pendulum 286The Upshot 288Conclusion 289  Chapter 32: Frameworks Are Details 291Framework Authors 292Asymmetric Marriage 292The Risks 293The Solution 294I Now Pronounce You … 295Conclusion 295  Chapter 33: Case Study: Video Sales 297The Product 298Use Case Analysis 298Component Architecture 300Dependency Management 302Conclusion 302  Chapter 34: The Missing Chapter 303Package by Layer 304Package by Feature 306Ports and Adapters 308Package by Component 310The Devil Is in the Implementation Details 315Organization versus Encapsulation 316Other Decoupling Modes 319Conclusion: The Missing Advice 321   Part VII: Appendix 323Appendix A Architecture Archaeology 325  Index 375

1. 5/5

   Important guidelines.

   The book describes how to use a plug-in architecture to create a clean and robust system design. It is a complement to books like "Effective Java" by Joshua Bloch in being more of an introduction to the discussions in Blochs book (which is very good). That is being an introduction to design of systems, using building blocks like classes/interfaces and reusable components. I found part three "Design principles" ( SOLID) and part four "Component principles" very useful. The book summarizes the discussions with a comprehensive Use case analysis in chapter 33. This is not a book for beginners, though.

   Tom V

   30 september 2018

Robert C. Martin (“Uncle Bob”) has been a programmer since 1970. He is founder of Uncle Bob Consulting, LLC, and cofounder with his son Micah Martin of The Clean Coders LLC. Martin has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He has authored and edited many books, including: Designing Object Oriented C++ Applications Using the Booch Method, Patterns Languages of Program Design 3, More C++ Gems, Extreme Programming in Practice, Agile Software Development: Principles, Patterns, and Practices, UML for Java Programmers, Clean Code, and The Clean Coder. A leader in the industry of software development, Martin served for three years as editor-in-chief of the C++ Report, and he served as the first chairman of the Agile Alliance.

Select Guide Rating

• Foreword xvPreface xixAcknowledgments xxiiiAbout the Author xxv   Part I: Introduction 1  Chapter 1: What Is Design and Architecture? 3 The Goal? 4Case Study 5Conclusion 12  Chapter 2: A Tale of Two Values 13Behavior 14Architecture 14The Greater Value 15Eisenhower’s Matrix 16Fight for the Architecture 18   Part II: Starting with the Bricks: Programming Paradigms 19  Chapter 3: Paradigm Overview 21 Structured Programming 22Object-Oriented Programming 22Functional Programming 22Food for Thought 23Conclusion 24  Chapter 4: Structured Programming 25Proof 27A Harmful Proclamation 28Functional Decomposition 29No Formal Proofs 30Science to the Rescue 30Tests 31Conclusion 31  Chapter 5: Object-Oriented Programming 33Encapsulation? 34Inheritance? 37Polymorphism? 40Conclusion 47  Chapter 6: Functional Programming 49Squares of Integers 50Immutability and Architecture 52Segregation of Mutability 52Event Sourcing 54Conclusion 56   Part III: Design Principles 57  Chapter 7: SRP: The Single Responsibility Principle 61 Symptom 1: Accidental Duplication 63Symptom 2: Merges 65Solutions 66Conclusion 67  Chapter 8: OCP: The Open-Closed Principle 69A Thought Experiment 70Directional Control 74Information Hiding 74Conclusion 75  Chapter 9: LSP: The Liskov Substitution Principle 77Guiding the Use of Inheritance 78The Square/Rectangle Problem 79LSP and Architecture 80Example LSP Violation 80Conclusion 82  Chapter 10: ISP: The Interface Segregation Principle 83ISP and Language 85ISP and Architecture 86Conclusion 86  Chapter 11: DIP: The Dependency Inversion Principle 87Stable Abstractions 88Factories 89Concrete Components 91Conclusion 91   Part IV: Component Principles 93  Chapter 12: Components 95 A Brief History of Components 96Relocatability 99Linkers 100Conclusion 102  Chapter 13: Component Cohesion 103The Reuse/Release Equivalence Principle 104The Common Closure Principle 105The Common Reuse Principle 107The Tension Diagram for Component Cohesion 108Conclusion 110  Chapter 14: Component Coupling 111The Acyclic Dependencies Principle 112Top-Down Design 118The Stable Dependencies Principle 120The Stable Abstractions Principle 126Conclusion 132   Part V: Architecture 133  Chapter 15: What Is Architecture? 135 Development 137Deployment 138Operation 138Maintenance 139Keeping Options Open 140Device Independence 142Junk Mail 144Physical Addressing 145Conclusion 146  Chapter 16: Independence 147Use Cases 148Operation 149Development 149Deployment 150Leaving Options Open 150Decoupling Layers 151Decoupling Use Cases 152Decoupling Mode 153Independent Develop-ability 153Independent Deployability 154Duplication 154Decoupling Modes (Again) 155Conclusion 158  Chapter 17: Boundaries: Drawing Lines 159A Couple of Sad Stories 160FitNesse 163Which Lines Do You Draw, and When Do You Draw Them? 165What About Input and Output? 169Plugin Architecture 170The Plugin Argument 172Conclusion 173  Chapter 18: Boundary Anatomy 175Boundary Crossing 176The Dreaded Monolith 176Deployment Components 178Threads 179Local Processes 179Services 180Conclusion 181  Chapter 19: Policy and Level 183Level 184Conclusion 187  Chapter 20: Business Rules 189Entities 190Use Cases 191Request and Response Models 193Conclusion 194  Chapter 21: Screaming Architecture 195The Theme of an Architecture 196The Purpose of an Architecture 197But What About the Web? 197Frameworks Are Tools, Not Ways of Life 198Testable Architectures 198Conclusion 199  Chapter 22: The Clean Architecture 201The Dependency Rule 203A Typical Scenario 207Conclusion 209  Chapter 23: Presenters and Humble Objects 211The Humble Object Pattern 212Presenters and Views 212Testing and Architecture 213Database Gateways 214Data Mappers 214Service Listeners 215Conclusion 215  Chapter 24: Partial Boundaries 217Skip the Last Step 218One-Dimensional Boundaries 219Facades 220Conclusion 220  Chapter 25: Layers and Boundaries 221Hunt the Wumpus 222Clean Architecture? 223Crossing the Streams 226Splitting the Streams 227Conclusion 228  Chapter 26: The Main Component 231The Ultimate Detail 232Conclusion 237  Chapter 27: Services: Great and Small 239Service Architecture? 240Service Benefits? 240The Kitty Problem 242Objects to the Rescue 244Component-Based Services 245Cross-Cutting Concerns 246Conclusion 247  Chapter 28: The Test Boundary 249Tests as System Components 250Design for Testability 251The Testing API 252Conclusion 253  Chapter 29: Clean Embedded Architecture 255App-titude Test 258The Target-Hardware Bottleneck 261Conclusion 273   Part VI: Details 275  Chapter 30: The Database Is a Detail 277 Relational Databases 278Why Are Database Systems So Prevalent? 279What If There Were No Disk? 280Details 281But What about Performance? 281Anecdote 281Conclusion 283  Chapter 31: The Web Is a Detail 285The Endless Pendulum 286The Upshot 288Conclusion 289  Chapter 32: Frameworks Are Details 291Framework Authors 292Asymmetric Marriage 292The Risks 293The Solution 294I Now Pronounce You … 295Conclusion 295  Chapter 33: Case Study: Video Sales 297The Product 298Use Case Analysis 298Component Architecture 300Dependency Management 302Conclusion 302  Chapter 34: The Missing Chapter 303Package by Layer 304Package by Feature 306Ports and Adapters 308Package by Component 310The Devil Is in the Implementation Details 315Organization versus Encapsulation 316Other Decoupling Modes 319Conclusion: The Missing Advice 321   Part VII: Appendix 323Appendix A Architecture Archaeology 325  Index 375

1. 5/5

   Important guidelines.

   The book describes how to use a plug-in architecture to create a clean and robust system design. It is a complement to books like "Effective Java" by Joshua Bloch in being more of an introduction to the discussions in Blochs book (which is very good). That is being an introduction to design of systems, using building blocks like classes/interfaces and reusable components. I found part three "Design principles" ( SOLID) and part four "Component principles" very useful. The book summarizes the discussions with a comprehensive Use case analysis in chapter 33. This is not a book for beginners, though.

   Tom V

   30 september 2018