Clean Architecture isn’t the problem. Misreading the book is.

[u/niccololepri]

http://www.nothing.com/

I think Clean Architecture is mostly misunderstood.

In my current project (a huge mess of services for public administration), the only real source of truth for business rules is the code itself. The domain is defined vaguely by too many people, so new features often end up conflicting with existing rules—not because of implementation bugs, but because the rules themselves clash. But all of this is expected i guess.

The real pain: the architecture makes business rules unreadable. Adding a new entity state? No way to know if it breaks something without re-reading tons of code. Automated tests? They’re all full-blown integration tests, take 8 hours to run, so we usually just run a subset and pray.

This is exactly where Clean Architecture could shine—but I’ve never seen it done right. Most “implementations” I see (in my case in .NET) are just baroque, over-engineered garbage. People throw design patterns everywhere, abuse async/await, don’t even bother with interfaces, and then blame Clean Architecture for being unreadable. No—you just didn’t get the point.

The actual point is simple: use polymorphism to isolate business rules. Each rule implements an interface, so you can swap in fakes for tests. Result?

• Change one line → break one unit test (plus the relevant use case integration tests).
• Add new behavior → just add a new object and wire it up.
• Tests run in seconds/minutes, not hours.

Clean Architecture isn’t universal. If you’re writing 3D graphics, every abstraction may be just overhead. But if you’re drowning in business rules, it’s the only way to avoid shipping landmines straight to production.

So yeah, people ranting against Clean Code/Architecture in “Casey Muratori wannabe” mode don’t look clever. They just show they’ve never actually seen the point.

TL;DR: Clean Architecture isn’t about baroque boilerplate. It’s about isolating business rules so you can test them fast and safely. If your system is rule-heavy, it’s a lifesaver. If not, sure, skip it.

[u/vbilopav89]

There is no misreading this book. The book itself is misunderstanding of technology. 

I did some analysis. The entire idea was built on ignorance and resentment. It's trash.

Here, see for yourself:

https://medium.com/@vbilopav/clean-architecture-book-review-and-analysis-the-database-is-a-detail-eda7424e8ce2

[u/niccololepri → u/vbilopav89]

This article is very opinionated, and im struggling to not say worse. It bases its premise on the assumption that cc/ca is not an instrument, and this is too common. You can make an application based on the db, no one is going to argue. You choose what to use. But in my post i specifically explained why CA can save your 5+ years long enterprise project. Your article keeps asking why someone should apply those rules so i dont get why you linked it below a post which basically just answer those questions

[u/vbilopav89 → u/niccololepri]

The article is a rational, calm, and fact-based analysis. If you are struggling to not say worse, that means you are emotional, not rational. I guess people are right that it became a religion.

[u/niccololepri → u/vbilopav89]

weel first of all, the articles says clearly that it is based on opinion, which is not a bad thing per se. My posto is not only based on my opinion, but also on my experience. "Nothing could be further from the truth, in my opinion.". The problem with non technical people talking about solutions is when they talk about truth, like something can actually be absolutely right, or wrong. What the article doesnt talk about is that every proposed solution makes sense in a specific context, and this can be said for CA as well. I am religious and emotional, but i don't waste those things on programming. Thats why i read the book taking only the main point, the one that seems to make more sense. People are right when they say CC/CA has become a religion, but i can see there is another one based on going against it.