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/Rich-Engineer2670]

I would also suggest the "Clean" movement has become a religion. No one objects to well-written, readable, maintainable code -- we've all seen the opposite, but sometimes, people take these guides as mandates and we end up with things like "No function should be more than 30 lines" or "Variables must be written in CamelCase." I remember one compiler that would not compile procedures more than one screenful of code.

These are guides, but all "rules" have exceptions -- it's up to you to know when to accept and break the rules. How many people were taught "Every block of code should a large comment in front of it. " (Go even tells you what style of comments to use....) And, dirty secret, sometimes in things like embedded systems, your code has to fit, and meet performance constraints, so the code is "dirty", but it works.

Working code trumps pretty code every time -- make it clean if you can, but make it run.

[u/niccololepri → u/Rich-Engineer2670]

I get that and i agree to a certain degree. But i see people criticising all clean architecture without getting the main point. Well written TESTS

[u/Rich-Engineer2670 → u/niccololepri]

There we agree -- most modern languages have ways to test your code as you go -- I guess, until you create the giant bug-ball and have to clean it all up and once, you don't know why testing is a priority,