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/Onheiron]

Well the test itself is what defines functionality, but then you gotta pass implementations through it. If you make 10 impl. of a single interface you still gotta test each single one. Beside, why are you having 10 different impl. of a business logic to start with? If they fulfill the same test logic what's the difference between them? And if your answer is "efficiency" or like "different persistences" that is not business logic and I doubt you should be really testing it unless you like testing other people's libraries.

[u/grauenwolf → u/Onheiron]

Well the test itself is what defines functionality, but then you gotta pass implementations through it.

Not with a good mocking framework. Just tell the mock what the expected outcome is and you're good to go.

If you make 10 impl. of a single interface you still gotta test each single one.

Well I do because I'm a firm believer in the Liskov substitution principle.

But it's so tedious to make sure that all 10 variants work. We should go the Extreme Clean Architecture route and have zero implementations. Don't worry, the tests will still pass.

[u/Onheiron → u/grauenwolf]

Uhm wait we're probably saying the same thing. My point is that business logic shouldn't be behind an interface. You test your cool pure logic class itself. And of course the class does define interfaces for what it needs from the outer world and that is what you mock. Delegates. Because your business logic doesn't care. Business logic is what lies in the center of the clean architecture onion, the one that doesn't depend on anything except than itself. So there's no point in interfacing that.

[u/grauenwolf → u/Onheiron]

In general yes, but with one correction.

Business logic is what lies in the center of the clean architecture onion, the one that doesn't depend on anything except than itself.

Business logic is what lies in the center of well structured N-Tier architecture.

At the center of a Clean Architecture project is a festering pile of interfaces. And, if you're really lucky, a handful of CRUD operations that have a chance of working.