I gave up on Clean Architecture after about one chapter. There's a section where he's graphing the number of lines of code in a hypothetical company's codebase over time - it grows rapidly at first and then it levels off, and he points at this like it means anything, specifically like it's a bad thing and it means the software has become difficult to work in. Also this isn't a line chart, it's a bar chart, and the X axis isn't time, it's unlabeled - eventually, in the text, you find that there's one bar per major release of the software, if that tells you anything about how retro this conception of software development is. Another bar chart shows the number of developers growing rapidly, as if that means anything either... It was just baffling.

I personally find that those two videos are much better at conveying the foundational knowledge needed to invent and understand something like Clean Architecture than the book itself:

https://www.destroyallsoftware.com/screencasts/catalog/funct...

https://www.destroyallsoftware.com/talks/boundaries

It seems unrelated in the surface, but I feel like they explain the "why" of a software architecture in a much simpler way and without the prescriptive and hand-wavy "trust me" nature of most software architecture books.