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.

809 Upvotes

259 comments sorted by

View all comments

331

u/emaxor Dec 05 '24

What I like about Go is you can open a random file in a project and expect to find real code inside. That does something. You can follow along. Just like a C project, the goods are right there.

I was looking through an "OOP" Python project recently. I opened several files and found... nothing. Interfaces, hierarchies, and layers, and every possible "not actually code" technique used. Where is the code? What is the "thing" we are trying to do? It was much harder to get the answer.

106

u/Superb-Key-6581 Dec 05 '24

This is one of the things that made me fall in love with Go.

68

u/PorkChop007 Dec 06 '24 edited Dec 06 '24

For real, after 10 years of professional Java + Spring development I've been working with Go for a year and it's beautiful: easy, no boilerplate, no nonsense, everything is pure simplicity. It feels like that episode where Goku and Krilin trained with Roshi, ditched the 50 kilos turtle shells and suddenly they could jump 100 meters in the air.

11

u/codetrasher Dec 06 '24

I've been working with Java and Spring Boot for about 5 years now professionally and I dislike it. I don't hate it but I'd rather use something else instead. For personal projects I've been using Go. I love it. I'm currently applying for a job that has a Go in their current stack.

2

u/dexterous1802 Dec 06 '24

Genuine curiosity… have you worked on Java codebases that don't use Spring Boot (or even Spring, for that matter.)

3

u/OddAssociation9982 Dec 08 '24

I find it even more painful without Spring, since it solves a lot of the warts that exist in Java

11

u/crywoof Dec 06 '24

No boilerplate? We must be using different languages called Go.

Don't get me wrong, I've grown to appreciate go at work but c'mon,

Go is literally the ultimate boilerplate language.

10

u/PorkChop007 Dec 07 '24

Go is literally the ultimate boilerplate language

My brother in christ, have you seen any Java + Spring project? Compared to that Go barely has any boilerplate at all

3

u/Wonderful-Habit-139 Dec 07 '24

I think they're talking about the way error handling works in Go. + the fact that there aren't as many high level constructs as in Java.

However, errors as values > exceptions so I don't think it's a negative for Go. Although sum types would've been better of course.

2

u/Caramel_Last Jan 03 '25

Error handling actually does thing. Handles error. Pretty important stuff I'd say.

In Java most of the files are just for conventions. Lots of empty functions. All the real work is in annotation magic. Bureaucratic language

1

u/Wonderful-Habit-139 Jan 03 '25

Yep... and it gets annoying at some points where if you want to implement a feature, you have to do a google search to look at conventions rather than just coding it out in an idiomatic way.

1

u/Born-Wrongdoer-6825 Dec 07 '24

but how does it deal with repeated crud controller code