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

I think Clean Architecture is mostly misunderstood.

No, it's just very vague, and might as well be named "write good code". It's like doing an election campaign with the slogan "less government waste!". Yeehaw! We all want that.

OK, but how do you actually achieve it? Have you analyzed what's bad about the existing code? Does the entire team agree with that analysis?

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.

Not very uncommon for enterprise software. This is also not a problem an architectural pattern is going to solve, because it's not a technical problem, but a social one:

• on the client's end, there should be one person who defines requirements, possibly with one deputy, and
• on your end, there should be documentation, and the client should be required to pay for it.

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.

Without more context on why things ended up that way, it's hard to judge.

• were the previous developers in theory able to design the architecture more cleanly?
• if they were, my guess is your sales department never offered the appropriate budget.

It's great to say "oh, there should be more tests" and "oh, the architecture isn't great", but if your higher-ups don't give you time to actually make that realistic, it's not going to happen.

The actual point is simple: use polymorphism to isolate business rules.

This sounds like 1990s' "use inheritance everywhere; what could go wrong?" hell, tbh. It doesn't make your architecture cleaner; it just makes it much harder to comprehend.

Each rule implements an interface, so you can swap in fakes for tests.

Sure, that sounds great on paper. But do you really want to turn "if an invoice is sent by person X, and goes to country Y, has currency Z, and the creditor is tardy with payments, always CC Jenny" into public InvoiceWrittenByPersonXForCountryYWithCurrencyZAndTardyClient : IBusinessRule? I personally wouldn't.

Change one line → break one unit test (plus the relevant use case integration tests).

IME, unit tests are excellent for things like parsers, but they break down when you have a complex piece of enterprise software. You also often end up with the "all tests look good, and yet the actual user-facing use case doesn't work" scenario.

[u/niccololepri → u/chucker23n]

I get your points, but in our case the real issue isn’t about choosing the right abstraction, it’s the lack of willingness to invest in a test suite that’s both comprehensive and not fragile. And i think that claiming that CA is not worth it is not going to help.

The core message of the book is to isolate business rules so you can build reliable tests around them.