Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Practical Software Architecture Solutions from the Legendary Robert C. Martin (“Uncle Bob�) By applying universal rules of software architecture, you can dramatically improve developer productivity throughout the life of any software system. Now, building upon the success of his best-selling books Clean Code and The Clean Coder, legendary software craftsman Robert C.
Martin (“Uncle Bob”) reveals those rules and helps you apply them. Martin’s Clean Architecture doesn’t merely present options. Drawing on over a half-century of experience in software environments of every imaginable type, Martin tells you what choices to make and why they are critical to your success.
Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Click here to readmore
Book Detail
Series: Robert C. Martin Series Paperback: 432 pages Publisher: Prentice Hall; 1 edition (September 20, 2017) Language: English ISBN-10: 0134494164 ISBN-13: 978-0134494166
Read more
I was hesitant to buy this book because Uncle Bob is known in software community as a fundamentalist zealot for his views on software design and testing (TDD). This book starts out with similar hard views and he claims that a useless program that is easy to maintain is better than a useful program that is impossible to maintain. I have seen a lot of bad design and implementations in my twenty plus years of experience as a software architect/engineer but nothing is impossible. As a profession software engineer, you are expected to support business and have to work with various constraints in your organization. These constraints vary based on the context and unique environment, which is why I prefer Kent Beck’s advice of making it work, making it right (refactoring) and making it fast. Most of first one third of the book provides overview of programming paradigms such as structured design, object oriented, and functional decomposition. He then covers SOLID principles that he is best known for, i.e. single responsibility principle (SRP), open-close principle, liskov substitution principle, interface separation principle (ISP) and dependency inversion principle. In my opinion, these principles can be boiled down to interface/implementation separation and using composition over inheritance (concrete). He then applies these principles to components design such as reuse/release equivalence principle for releasing same component together, common closure principle similar to SRP and common reuse principle for using interfaces similar to ISP. Uncle Bob provides useful advice for using acyclic dependency principle for dependencies between components and ensuring that abstract/interfaces are used in stable components and volatile components (concrete implementation) should depend on stable components and not otherwise. The last one quarter of the book finally starts with explanation on clean architecture that uses hexagonal architecture. He states that architecture should be independent of frameworks, UI and database. His definition of architecture only focuses on component design and communication but I use architecture as any design decision that is costly to change and often that include choice of databases, frameworks and UI. He uses layers and boundaries to divide system into various components and recommends use of entities for
business policies, using techniques such as humble object pattern for testing hard to test components. In final chapters, he proposed designing components based on use cases instead of horizontal, which has worked better in my experience when working on a large system. In the end, this book has plenty of nuggets on design of components but take this advice with a grain of salt. Uncle Bob’s militant views on clean design, test driven development and his abhorrence for tools is not very pragmatic. For example, he doesn’t mention technical debt, refactoring or dealing with legacy systems. Though, he pays attention to maintainability but he ignores most of other non functional requirements such as scalability, availability, reliability and ignores emphasis on developer productivity. In my experience, software design and development should start with the business requirements, constraints and organization structure. You may be working in a startup that needs to prove an idea with minimal effort or you may be working on designing a service with a large number of users. Similarly, you may be working with a small team or on a large project that needs to interact with a number of teams where you may need to apply Conway’s law to design the system. In real world, you face these choices instead of writing perfect components with 100% test coverage, which may be maintainable but not useful to anyone and thus killing your company and leaving you without work.
thanks for reading