🌱Unclean Architecture Lecture
Unclean Architecture
I assume everyone who writes code knows about a very famous book in the software industry?
This book is called Clean Architecture, written by Robert C. Martin (Uncle Bob).
He is even more famous for Clean Code.
However, I believe (and have searched myself) that there are too many blog posts or videos teaching these concepts.
So I thought, there's no need for me to add just another flower to the bouquet.
Yukio Mishima's book Lectures on Immoral Education has been constantly reprinted since I first read it, showing how well it sells!
Why don't I write an "Unclean Architecture Lecture" instead!
1. What's the problem with Layered Architecture?
There is no problem!
Layered Architecture is the standard.
The traditional three-layer architecture is: Presentation Layer (Web), Domain Layer, and Data Access Layer.
Web is the user interface, the Domain layer is responsible for business logic, and the Data Access layer handles communication with the database.
Its purpose is to have clear boundaries between layers, letting each layer be responsible for its own work.
This is simply too clean; it creates maintenance hardship. Ideally, we could just grab data quickly, but instead, we have to exchange it through layer after layer.
Your Controller just wants to go to the database to get a record and display it on the screen, Why does it have to go through the Service layer? And then through the Repository layer? Isn't this just taking off your pants to fart?
We can call Entity Framework's DbContext directly in the Controller,
One line of code _db.Users.ToList() and it's done!
How intuitive!
It's like not going through a waiter; the customer goes directly to the chef in the kitchen to ask for food, saving time.
1. Database Driven Design
In traditional layered architecture, the bottom layer is usually the database.
Typically, domain logic or business logic hopes to decouple from any other objects.
Business logic should be considered for correctness first, before adding database access logic.
However, in our Database Driven Design, as the name implies, we focus on database access, and business logic becomes secondary.
Why?
Think about it: if you always focus on business logic but ignore whether the data is correct, isn't that a problem?
2. Cheating in the Layers
We can call this a "Relaxed Layered System".
This is where the benefit of "cheating" comes in!
We call Entity Framework's DbContext directly in the Controller. One line of code _db.Users.ToList() and it's resolved! How straightforward, how efficient!
Although textbooks will say this leads to "Logic Leakage" and "Tight Coupling between UI and Database", who cares? As long as it works now. If the database fields act up later, we can just enjoy the thrill of "Global Search and Replace". This is the romance of engineers working overtime!
If every layer is strictly guarded, how are we supposed to demonstrate our magical speed of "Rapid Delivery"?
3. Hard to Execute Tests
Do you feel that writing Unit Tests is a waste of time?
Congratulations, traditional layer architecture fully supports your view!
Because our architecture is "Database Driven", all business logic relies heavily on the database.
If you want to test the logic of "calculating order discounts", you must first start a real SQL Server,
Then insert fake data, and after running the test, remember to delete the data.
This is simply wonderful!
Because testing is so difficult (it can even be said to be "untestable"),
We have the perfect excuse to tell our manager: "Due to architectural limitations, the cost of writing unit tests is too high and the ROI is low. Let's just manually test it!"
This not only saves time on writing Mock objects but also gives the testers (QA) something to do, creating job opportunities.
In contrast, Clean Architecture emphasizes "testing without relying on UI or DB",
Which is simply depriving us of our right to be lazy.
4. Where are the Use Cases?
When you open a project and see folder structures like Controllers, Views, Models, Helpers, how do you feel?
You see a bunch of "technical terms", but you can't tell at all "what" this software does. This is the opposite of the so-called "Screaming Architecture"—it is "Silent Architecture".
This is very helpful for maintaining a sense of mystery!
If your project structure clearly says CreateOrder, CancelSubscription,
Then wouldn't a new colleague understand what the system is doing in one day? Where would you put your "Senior" status then?
The best architecture is to hide "Use Cases" inside thousands of lines of Controllers or Services.
Want to know how the system works? Read the code slowly!
This is like playing a treasure hunt, scattering business logic across the UI layer, SQL Stored Procedures, and various Helpers, effectively preventing the core technology from leaking out.
5. Difficult Parallel Distributed Work
Under this layered architecture, developing a new feature usually requires "penetrating" all layers. You need to change the UI, change the Controller, change the Service, change the DAO, and change the Database.
What does this mean?
If three people are developing three features at the same time, everyone will be crowded into the same UserService.cs or OrderController.cs to modify.
This is an excellent opportunity to promote team communication.
Conflicts will definitely occur during Git Merge. At this time, you have to turn around and talk to your colleague: "Hey, why did you overwrite my code?" or "Why did you change this Public Method without telling me?"
This architecture forces everyone into "close contact", which is definitely more effective than any Team Building activity. In contrast to those architectures that emphasize "Vertical Slicing" or "Functional Independence", where everyone does their own thing—how cold and indifferent!
6. How to steer software towards the goal of maintainability?
If you are an engineer who is naturally conservative, dislikes adventure, hates working overtime to fix bugs, and hopes your phone doesn't ring after get off work, then you might think the "advantages" mentioned above sound like hell.
Is this really what you want?
- first edition time: 2026-01-21
- last edit time: 2026-01-25