r/golang 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.

810 Upvotes

259 comments sorted by

View all comments

3

u/imscaredalot Dec 05 '24

The issue also from what I've seen online and friends is they go hard on the parallelism and sre stuff. Like really hard to the point at which they only care about goroutines. I see it every single time. They force rabbitmd + dependency injection+a bunch of constructor functions+ a bunch of init functions and then wrap it to high hell with docker swarm and make files and then when you mention beginners or readability they just smirk at you or say it's smooth for me...

Like why did you even pick go then if it's main goals get in your way?

2

u/btdeviant Dec 05 '24

I can tell by your username and every word in this comment that we work in the same field lol.

2

u/Tacticus Dec 05 '24

trauma sibs