Recently, this book, as well as Clean Code, has received plenty of negative feedback and skepticism with regard to its wisdom and applicability.<p>I am not yet experienced enough to assess such judgements, but I would really like to truly master this "clean architecture" if it ever exists.<p>Can you please comment on:<p>* What you think is wrong with Clean Architecture and how bad it really is<p>* What you can recommend instead<p>FWIW, my programming language of choice is Go so a lot of things typical of Java (for example) are not directly applicable here. Even worse, some of them might do more harm than good whereas Go aims for simplicity. Nonetheless, with the elegant interfaces in Go, it feels like it fits the SOLID philosophy even better, but someone has yet to extensively cover that.
The PC discussion is like tabs vs spaces and will never be resolved because people will always have different opinions. Anyone that puts themselves in public view like this will attract more attention and generate opinions of all types. I don't let that figure into the larger technical decisions I need to make.<p>Uncle Bob's writing, teaching, and speaking is widely known and feels like something that a lot of developers know about. Because of this, it's important to know about. Further, he has a lot of useful ideas that developers can use to make their software better. Note that many of the things he discusses aren't new and have been around for a long time. He just re-packages it in a way that a lot of developers find useful. More knowledge gives us all more tools to get our jobs done.<p>My annoyance around SOLID and any other ideology in software engineering is the near religious fervor around it. A little research will show that many developers are promoting these concepts as "The Best Practice" or "If You Aren't Doing SOLID, You're Doing it Wrong" and similar declarations. I believe this approach is myopic because there are many different approaches and ideas on how to build software.<p>I'm in the camp of looking at a project and setting up practices, processes, and standards that make sense for the application and team you're working with. Some of it is likely to align with some SOLID principles. Our industry changes all the time and we need to be flexible in how we adapt to new tools and new ideas, respecting the various ideas and approaches that evolve over time.
This is only my opinion but I believe this is only happening because Uncle Bob refuses to submit to political correctness.<p>It's still a solid resource, you should not treat it as your Bible of course. There is not a single resource that will teach you how to write clean code or clean architecture.<p>You need to read about design patterns, and then you will abuse them, so you need to step down, reflect and see them for what they are.<p>You need to learn to name things well. Most functions can be short and expressive. The code can speak for itself (most of the time)<p>You need to spot reusability, to know when you are being too clever, you need to go down the rabbit hole until you see for yourself, that this is obviously not the right way to do it.<p>This takes times, and there is no exact recipe. It's similar to chess, sure you can learn many openings and closing, but 90% of the game is sensing the board, seeing patterns as a whole.<p>In this journey, Uncle Bob is a pretty good teacher, he will show you code you could have produced by yourself, code that I could have produced myself. And show you why it's flawed, why it would be hard to extend, modify. Why it will be hard to read several months from now.<p>And he will teach some good principles you can use to write better code.