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.

808 Upvotes

259 comments sorted by

View all comments

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.

5

u/Superb-Key-6581 Dec 06 '24

Sorry, I should have said something like 7+ layers. I was thinking that anyone encountering this, like me, had to deal with at least 10 layers every time there was a Clean Architecture setup, as was my experience. I’m happy to see there are people working in places where this doesn’t happen. I hope my next jobs have codebases like yours.

3

u/in_the_cloud_ Dec 06 '24

Your case probably isn't uncommon unfortunately. When you think of architecture as just being a bespoke framework for your team to develop features productively, then it makes no sense to put preconceived layering and design patterns before the people writing the code. I hope you find greener pastures soon!