Blog #35: Clean Architecture – The Dream and the Harsh Reality

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:

1. 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.