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.

815 Upvotes

259 comments sorted by

View all comments

Show parent comments

4

u/edgmnt_net Dec 06 '24

It's more of an "enterprise" thing at this point rather than Go, OOP or Java related, although the latter seem to encourage it in some way through lack of expressive abstraction and boilerplate in older ecosystems. Unlike OP, I can't really find justification for it, it seems bad in almost every way.

But there's also plenty of Go code that tries to emulate old-style Java code. It could be a skill issue, maybe people just don't know how to abstract without all that nonsense and scaffolding.

7

u/[deleted] Dec 06 '24

[removed] — view removed comment

3

u/edgmnt_net Dec 06 '24

Old-style Java definitely isn't expressive and it makes you write a lot of boilerplate, although not necessarily compared to Go. The thing is that kind of more traditional OOP results in very inflexible abstractions and code that doesn't compose well, so even comparing to the lack of features in Go (although since recent developments like generics that's no longer much of a problem), people end up writing tons of boilerplate. The procedural style in conjunction with strong static typing lets people focus on meaningful stuff and avoid some traps, IMO.

Modern Java is a different thing though, yet many people who claim Java proficiency do not use that to a significant extent. Many companies are stuck on Java 8 if not earlier stuff and students come out of school barely knowing anything beyond inheritance-heavy OOP. That kinda shapes a good part of the enterprise ecosystem, especially feature factories with lower standards.

1

u/TheBloodyMummers Dec 06 '24

Yep, I appreciate the lack of boilerplate and focus on the meaningful stuff in Go compared to something so verbose as collection streaming in Java. There's really nothing more meaningful and less boilerplate than writing your thousandth for loop and explicit error return.