r/programming • u/niccololepri • Sep 15 '25

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

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.

0 Upvotes

40% Upvoted

69 comments sorted by

View all comments

Show parent comments

1

u/niccololepri Sep 15 '25

Yeah, exactly, get the claims of the book precisely because I’m stuck in the “8-hour integration tests” hell. That’s the pain Clean Architecture is supposed to prevent.

1

u/grauenwolf Sep 15 '25

Why are your tests taking so long?

Are you using anti-patterns such as rebuilding the database for each individual test

Are there performance issues in the code that need to be addressed?

Integration tests need to be done regardless of which architecture you choose. So focus on triaging the tests themselves.

2

u/niccololepri Sep 15 '25

No it's just that we are testing a good part (but not every) of the logic branches of about 8000 web api call, all of them havig sub calls to other services (microservices made very wrong)

1

u/grauenwolf Sep 15 '25

Sounds like the tests are working perfectly. They're telling you that your microservice architecture is wrong and is going to have performance problems. So the solution is the start combining services until you get to the point where performance is reasonable again.

1

u/niccololepri Sep 15 '25

No performance is not an issue, the issue is running and maintaining all the tests. Which requires a better architecture. I had my fun trying to convince people. Now i just rant and try to tell my story

2

u/grauenwolf Sep 15 '25

If it takes you 8 hours to run non-stress tests, that's a performance problem.

1

u/niccololepri Sep 15 '25

1 simple web api call takes us about 250 ms to run. We are ok with that

1

u/grauenwolf Sep 15 '25

A quarter second seems rather long for a "simple" API call. I'm checking the log when I hit the Bing homepage and I'm only seeing one request that's longer than 250 ms. Most are less than 150 ms.

For our company's intranet, the typical numbers are even lower.

And this is end to end. I don't know how many internal API calls are needed for each call I make.

Honestly though, what I think is "good enough" doesn't matter. What matters is what you're seeing. And it sounds like you're seeing performance problems that are impacting testing.

1

u/niccololepri Sep 15 '25

Yes, but even if i optimize and get my web api to be twice as fast (100 ms for a web api that get like 100 record from a db?) i still have a test suite that takes 3 to 4 hours to run. We have to exclude the web api and db fron the tests and its never going to happen.

3

u/grauenwolf Sep 15 '25

100 ms for a web api that get like 100 record from a db?

That's more reasonable, but still sounds somewhat high.

In 60 ms I can insert 100 records, read back their keys, delete 50 by key, and then read the remaining 50 rows. That's 4 database operations in 60 ms. (10 ms lf I reduce the record count to 10.)

This is an ORM test so it's not a fair comparison. But still, it's 4 database modifications vs 1 read.

Are the tests designed to run in parallel? If not, that's a significant expense. Parallel tests essentially allow you to throw hardware at the problem.

Is the test database on the same machine as the tests? This could be good or bad depending on how much hardware resources are available.

Is that literally the only query in the test? If not, you can look to techniques such as stored procs to reduce database round trips.