Blog #35: Clean Architecture – The Dream and the Harsh Reality
When over-applying Clean Architecture turns simple changes into a cumbersome and slow series of tasks.
2 min read
Closing in on a release deadline. The designer requested changing a label from "Full Name" to "Full Name" (Vietnamese context: "Full Name" -> "Tên đầy đủ") and sourcing it from a new field in the API. A task that seemed like it would take 2 minutes. But no, I was applying Clean Architecture mechanically to this project.
I opened my editor and began the journey through the layers:
Domain Model, 2.Data Entity, 3.Mapper, 4.Repository, 5.Use Case, and finally 6.UI Component.
I muttered under my breath: "Why did I make this so hard for myself?". I was writing dozens of lines of repetitive code just to display a simple label.
1. What happened?
The development process stagnated because the architecture was over-engineered. Even the smallest changes required updates across many intermediate layers, increasing the risk of errors and wasting time.
2. What I thought the cause was
I assumed it was because I didn't have fancy "Code Generator" tools to automate the creation of Boilerplate. I spent time researching code generation libraries instead of looking at the core issue.
3. How I debugged it
I ran a test: Measuring the actual time to add a new data field from the API to the UI. Results showed that 80% of the time was spent re-declaring near-identical Model/Entity classes at different layers.
4. The moment of realization
I realized I was applying architecture designed for massive enterprise systems to a medium-sized web application. Clean Architecture is truly great when business logic is extremely complex and needs to be completely independent of the Framework. But for this project, it was a chain holding back the speed of the whole team.
5. The fix
- Quick patch: Skip the Mapper in a few less critical spots and pass data directly from the API to the UI to make the deadline.
- Real fix: Simplify the architecture. Remove intermediate layers that don't provide real value. Apply the KISS (Keep It Simple, Stupid) philosophy: only abstract when absolutely necessary.
6. Looking back
Architecture exists to serve the project, not the other way around. Don't bring out a cannon to shoot a sparrow. If I were designing it again, I would prioritize pragmatism over the purity of architectural dogma.