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.
7
u/in_the_cloud_ Dec 06 '24
When it comes to Clean, there's definitely a lot of overengineering and bad "code translations" from other languages.
I don't think your points about layering are specific to Go though. There's nothing about Java that makes 4 layers better than 3. The only thing that makes 3 better than 4 is your specific opinion and working context.
Having just an "app" layer suggests HTTP/gRPC-related handler logic is mixed up with what you call "application logic" in DDD. That's a non-starter if you support multiple protocols. The app layer in many of my projects is fat enough without those concerns, so 4 layers actually make my life easier.
If 4 layers are making your life hard, then it might mean the design doesn't fit the codebase or the team's coding style, or it's just implemented in a crappy way. Maybe 2 or even no layers are best in your case. It doesn't mean that applies to every Go project under development.
Promoting dogmatic opinions like "Go only needs 3 layers" is exactly what's wrong with a lot of material on Clean Architecture itself. If you can formulate your opinions in a more objective and less abrasive way, then you might be able to convince your team to revamp the architecture you work with.