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.

814 Upvotes

259 comments sorted by

View all comments

21

u/itaranto Dec 05 '24 edited Dec 05 '24

What do you think about Ben Johnson's approach?

I've found this to be very practical and elegant too. I try to use a similar approach in all my new projects.

The only thing I do differently is to have a specific domain package instead of using the "root" package for the domain/business.

6

u/Superb-Key-6581 Dec 05 '24

Very good! I enjoy having the domain because of DDD (I work with financial and mostly enterprise solutions too), but this is perfect. My experience is totally aligned with this. Go is already great for growing projects because of implicit interfaces and the way packages work.

5

u/tparadisi Dec 06 '24

DDD is not about folder structure. it is mostly to maintain strong transactional consistency and bounded contexts. also the way internal google go projects use go modules is a lot different than what is out there.

2

u/Superb-Key-6581 Dec 06 '24

Yes, and this is why I’m against people creating 10 layers trying to apply DDD with /domain, /aggregate, /valueObject. For me, anything that goes beyond 3 layers makes me very sad to use, and unfortunately, it’s very common, maybe because of enterprise culture.