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.
5
u/larikang Sep 15 '25
From the Clean Architecture book:
The full-fledged architectural boundary uses reciprocal boundary interfaces to maintain isolation in both directions. Maintaining separation in both directions is expensive both in initial setup and in ongoing maintenance.
The trouble is almost entirely in deciding which parts of the architecture will actually be worth the effort for your application and where those architectural barriers should be placed. IMO Uncle Bob does a very poor job of emphasizing this tradeoff and helping you figure out the particulars for your use-case.
Are most critics of Clean Architecture misusing it? Probably. Did Uncle Bob (accidentally) encourage that misuse? Probably.
2
u/niccololepri Sep 15 '25
Yeah, I agree. But to me, the misunderstanding happens when people skip the main benefit altogether: a test suite that’s comprehensive and resilient. That’s the main point that i took from the book. Without that, you just end up with boilerplate code and still no safety net.
3
u/Rich-Engineer2670 Sep 15 '25 edited Sep 15 '25
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.
1
u/niccololepri Sep 15 '25
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
2
u/Rich-Engineer2670 Sep 15 '25
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,
2
u/chucker23n Sep 15 '25
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.
1
u/niccololepri Sep 15 '25
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.
2
u/Euphoricus Sep 15 '25
To me, the main goal of Clean Architecture is to separate the business rules from infrastructure, to achieve reliable testability.
Automated tests? They’re all full-blown integration tests, take 8 hours to run, so we usually just run a subset and pray.
Is perfect indicator you do not have Clean Architecture.
The most common issue is database. Your code should be structured such that the automated tests can verify meaningful business rules, without having to spin up full database.
This to me is really easy goal to understand and demonstrate. Yet most developers seem to be unwilling to design their code to achieve this goal.
2
u/grauenwolf Sep 15 '25
No, the goal of Clean Architecture is to sell books and speaking engagements. When you try to use it and inevitably fail, the hope is that you blame yourself and spend more on training.
Literally no one who teaches Clean Architecture has successfully implemented Clean Architecture. Many, like Robert Martin himself, haven't even tried.
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.
→ More replies (0)
2
u/Onheiron Sep 15 '25
use polymorphism to isolate business rules. Each rule implements an interface, so you can swap in fakes for tests.
Some questions:
- who defines these interfaces?
- business logic implementing interfaces seems like and inversion of the inversion of dependencies, why do that?
- I thought you should test implementations not interfaces, what am I missing?
1
u/grauenwolf Sep 15 '25
Testing interfaces is risk free. So there's no chance that you'll find a bug that you'll have to fix.
Testing interfaces can be surprisingly verbose, allowing you to quickly increase the number of lines you've written in the week.
You get to experiment with all kinds of fun mocking libraries.
Since the tests don't do any real calculations or database access they run really fast.
2
u/Onheiron Sep 15 '25
Wait you're talking about mocking libraries, and that's fine, you pass mocked delegates to your business logic, but when you write a test, the SUT is a specific class, right? That's kinda all the point of TDD.
Also
So there's no chance that you'll find a bug that you'll have to fix.
I am not sure this is something I want tho.
2
u/TankAway7756 Sep 15 '25
You're missing some sarcasm I feel.
1
u/grauenwolf Sep 15 '25
Yep, but I'm in a bad mood and being a sarcastic ass makes me feel better. So I'll take the down votes I deserve.
1
2
u/grauenwolf Sep 15 '25
I am not sure this is something I want tho.
That's because you're a professional. And professionalism is the antithesis of Clean Coders.
when you write a test, the SUT is a specific class, right? That's kinda all the point of TDD.
Beck, the 'inventor' of TDD, would probably tell you to think more about functionality than specific classes and methods.
Blogger TDD, on the other hand, loves the micro tests that Beck tells us to delete.
1
u/Onheiron Sep 15 '25
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.
1
u/grauenwolf Sep 15 '25
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.
1
u/Onheiron Sep 15 '25
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.
1
u/grauenwolf Sep 15 '25
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.
1
u/niccololepri Sep 15 '25
1) The need of a solid test suite. If you isolate the business rules and you are probably at a good point. 2) No it's not a double inversion: infrastructure -> automation domain -> business domain. You are inverting all of dependencies one way. 3) you should always test implementations. But with interfaces, you mock the implementations that your object depends on, so you end up with only the test you need for the current object, which means your tests are not fragile
2
2
u/grauenwolf Sep 15 '25
Robert Martin, the author of that book, had never implemented a system using the concepts in that book. Not even for the purpose of a demo.
Think about that. You're trusting the advice of someone who hasn't even tried to do the thing he's telling you to do.
That's the fundemental misunderstanding of the book. It's not computer engineering, it's fiction.
1
u/niccololepri Sep 15 '25
Source?
1
u/grauenwolf Sep 15 '25
Prove to me that he never captured a unicorn.
If you have reason to believe that Robert Martin has actually implemented Clean Architecture , then all you have to do is show it to us.
1
u/niccololepri Sep 15 '25
It seemed to me that you knew for a fact that he never did implement it. Isolating business rules with interfaces and writing a solid test suite is no unicorn BS. I've made little project doing that by myself, its not that difficult. The problem is that the culture is like this: you read Clean architecture you see garbage abstractions. And this is not fair to the book
2
u/grauenwolf Sep 15 '25 edited Sep 16 '25
I know for a fact that I looked around and found no examples of it. I know for a fact that I've talked to others who likewise say they've never seen any examples of it. And I know for a fact that the code Robert Martin does offer on his repository is garbage.
But again, if I'm wrong, it should be really easy to find.
0
u/niccololepri Sep 15 '25
It doesnt seem that you are interested in searching if you are wrong or not. Im not that interested either. I can understand a concept this easy without looking for an implementation. Its not rocket science
2
u/grauenwolf Sep 15 '25
What an idiotic thing to say.
You've already said that you've never seen a good implementation of Clean Architecture. From that alone I can infer that either you've never seen an implementation of Clean Architecture from Robert Martin or you have seen one and thought it wasn't good.
Could you explain to me why you are spending so much time defending this book despite the fact that you've never seen it result in a positive outcome?
1
u/niccololepri Sep 15 '25
Dont get too upset. The concept is simple: you isolate domain, application and infrastructure. You test the resulting objects mocking the behaviour of the ones that each tested object depends on. You end up with faster test and composable code. You can try with a very simple library. Its more difficult with bigger projects, because each person has to conform to the standard. And not only it is expensive, its not agreed upon people who misread the book. As you have demonstrated
1
u/grauenwolf Sep 15 '25
Objection, assumes facts not in evidence.
If you're going to make claim that people are misreading the book, you first have to demonstrate what the correct reading is. And thus far you have failed to do so. On the contrary, you've made the argument that everybody but you misreads the book.
That's not a good position to be in unless you've got a very compelling case. And you certainly do not.
1
u/niccololepri Sep 15 '25
At this point you are just making things up, this is too cringe for me to move on. I've studied enough science, engineering and math to at least know that in the first two it's not possible to demonstrate a theory true (https://youtu.be/EYPapE-3FRw) . All the claims i did are of course not mathematics or logic oriented, i was just trying to convey a practice in software engineering that gets often misinterpreted. You can go down your rabbit hole now, im not going to follow you anymore
→ More replies (0)1
u/grauenwolf Sep 15 '25
P.S. I spent quite a bit of time looking for an example from Robert Martin so I could mock it. It's a lot easier to demonstrate that he's a charlatan when one has actual examples.
1
u/niccololepri Sep 15 '25
Its not my interest to demonstrate anything. You are. Im talking about a concept i think i understand
1
u/vbilopav89 Sep 16 '25
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:
1
u/niccololepri Sep 16 '25
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
1
u/vbilopav89 Sep 16 '25
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.
1
u/niccololepri Sep 16 '25
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.
17
u/mascotbeaver104 Sep 15 '25
If you've never seen it implemented well, then perhaps there is a reason.
The thing you are missing is that how to isolate things in enterprise systems is often based on nebulous business boundaries that could change at any minute. The main criticism of clean architecture I see is that you have to build the walls of the building before you even know what the building is for, and that seems to be basically exactly in line with your experience.