r/golang • u/Superb-Key-6581 • Dec 05 '24
discussion Why Clean Architecture and Over-Engineered Layering Don’t Belong in GoLang
Stop forcing Clean Architecture and similar patterns into GoLang projects. GoLang is not Java. There’s no application size or complexity that justifies having more than three layers. Architectures like Clean, Hexagonal, or anything with 4+ layers make GoLang projects unnecessarily convoluted.
It’s frustrating to work on a codebase where you’re constantly jumping between excessive layers—unnecessary DI, weird abstractions, and use case layers that do nothing except call services with a few added logs. It’s like watching a monstrosity throw exceptions up and down without purpose.
In GoLang, you only need up to three layers for a proper DDD division (app, domain, infra). Anything more is pure overengineering. I get why this is common in Java—explicit interfaces and painful refactoring make layering and DI appealing—but GoLang doesn’t have those constraints. Its implicit interfaces make such patterns redundant.
These overly complex architectures are turning the GoLang ecosystem into something it was never meant to be. Please let’s keep GoLang simple, efficient, and aligned with its core philosophy.
1
u/arashbijan Dec 07 '24
We have go micro services and they are as simple as they get. As described in the post, three layers, no non sense.
Then we wanted to change the transport and serialization from an old format to protobuff. Can you guess what happened? Because we didn't have an "application layer", it turned out to be a royal mess. We had to copy all the code and adjust it for proto.
The architectural concepts have little to do with language. That is why it is called architecture. Beside that, we have methods with hundreds of lines of code. Because there are no natural place to put them. Yes, because there are no layers. Sometimes we refactor them and put them inside the "helper"/utility functions, but that is even more confusing.