Hi!
I’ve never read any of Uncle Bob’s books. But I have taken interest in “Clean Architecture” as it seems like a good solution to make mid to large sized projects simple to understand and maintain.
I think MVC gets too much coupling and fails at larger projects, same with n-tier. But I’m not sure about anything right now (software design is a very complicated problem after all).
So I was wondering if you friends who have used Clean Architecture in production can share your knowledge and experience with me about this design?
Is it actually good and worth investing in?
Footnote:
I’m especially weighing this architecture because Uncle Bob’s writings are really hit and miss. I don’t see him as a master or guru so I take everything he says with a grain of salt.
Have you read any other programming books? There is a few I could recommend before anything from uncle bob
For me Clean Code is a book I’m really thankful to have read early on, it’s got some good points on naming and separation of concerns especially. Apart from that I’m afraid that there’s no “architecture” that you could learn and follow in implementation and be perfectly happy.
From my point of view all architecture and patterns exist solely for inspiration, a bunch of it gives you good guidelines and if you understand them well enough you should be able to pick and pivot to one suitable to the task at hand. As soon as you start philosophising and following “rules”, you’ve lost. Software is complex enough that you can’t framework it all out beforehand with a set of constraints (otherwise LLM codegen would be a much more useful tool).
What you have to decide is what you care about from your software, does it need to change a lot, does it need to be extremely performant? Are you going to be doing a lot of repeated “data-piping” (DB-Backend-Frontend) or some super specific complex processing.
The frameworks give you nice starting points and rough infrastructure ideas based on your answers, but times and wants and needs all change regularly so you’ll always have to change something later, and that’s why I believe legibility, separation of concerns and a sane testing strategy are the most important parts of the equation, the rest may change with evolving requirements.
Thank you.
While I agree fully that there’s no “one size fits all” in software architecture, I think by knowing and understanding different architectures, we can follow 80% of an architecture which fits our requirements exactly, and focus on the dynamic 20%. Think of architecture in buildings. By knowing our environment, requirements, capabilities and budget, we can choose an architectural style, for example brutalism, traditional chinese, traditional central Persian etc. Follow most of it as a blueprint, and focus more on those new, dynamic parts based on the prior said factors.
Just a note, I’m talking about the book “Clean Architecture” not “Clean Code”
