Discussion on: Why I can't recommend Clean Architecture by Robert C Martin

I have a hard time following your reasoning why this book is not recommendable.

You state that the stories on design paradigms were unnecessary, yet you miss to say why. So why you think these were unnecessary (beside the fact that he basically told a story before any chapter he started in that book)?

You are stating that there are too few code samples in the book, but then the book never advertised to be a code repository (in any of its pages) or explain paradigms and principles by code.

And I would say that it's not what the book is about. It's more about a way of thinking as an architect than which code or programming language is explicitly used to create a good software architecture (he states that several times in the book btw). If he would have done that, which language you think he should have used? And what exact implementation would have been good or bad?

There are always tons of ways to implement something and if talking about principles and paradigms, that would have put some heavy burdon on him and any presented implementations.

Let me clarify what I mean:
We all know it, you are implementing some boilerplate code just for a test project of yours. Very dirty, just as a proof of concept. Still, there will be people coming to you, looking at the code, starting to tell you that there are more effective, more efficient, more beautiful, better maintainable ways (append arguments here endlessly) than the test code you have just written. And they start "enlightening" you from all possible perspectives.
They expect from you to defend your decisions while all you think is "hey man, I just wanted to see how that pattern works...".

Look at the reactions about your blog posting, very divided. This forces you to answer and justify yourself and your opinion.

Now think about his book and what would have happened if he had included sample code for his presentation of general insights on clean architecture. Eventually, that would have forced him to explain how the presented code fits the all-so-good architectural paradigms he has just talked about. Also 20 years from now, would that implementation still be valid or would other languages or implementations that will arise be more fitting? See my point?

Presenting implementation examples will inevitably force you down a road you cannot get off from and therefore he simply avoided putting that burdon on him (probably there wouldn't have been an implementation that fits it all). He stayed theoretical with a groundtruth that comes from practical experience. He didn't want to get too explicit about it.

I mean look at the blue book by Eric Evans about DDD. There is as good as no code at all in that book (500+ pages btw...phew), still it's the key work to the whole DDD world and that Martin Fowler states to be one of the biggest influences he had concerning DDD (while still saying it's hard to read).

And you may have misunderstood that this book is not about THE architectural way of doing things. Rather it's a summary of all the clean architectures that presented themselves over the years. Layered, Hexagonal, Onion, Microservices and all the shebang. They all have the same thing in common, they are clean architectures. They follow the dependency rules, they allow decoupling, they cherish maintenance and testability and they allow to use little human resources to gain high production value.

The book by Fowler you recommend is great, but it's a different book with a different mindset and a different goal than clean architecture.

It's like saying Eric Evans book on DDD is bad (because it's mostly theory) and Vaugn Vernonts book on IDDD is good (because it's tailored against practice). This is simply a biased opinion, which is fine but it's not fair to expose it as if it wasn't.

To me, Clean Architecture is the perfect summary of all the principles and paradigms that play a key role in the world of architectural fundamentals. Nothing more but definetly not less.