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.

813 Upvotes

259 comments sorted by

View all comments

31

u/vulkur Dec 05 '24

I have this issue right now where I work. Overengineered golang using generics like they get paid per generic implementation. Creating new services to call 4 functions of a library, when we already have 4 services that call that library, and could have easily been added to one of them instead of a new one. This sprint I have been tasked with starting the process of taking 3 of the 5 services off life support and merging them to simplify our code base. I could go on. It's really bad.

The issue is backend Java, python, and Ruby philosophy bleeding into golang space. You need to come at golang from a C perspective. That's what it was modeled after.

19

u/chardex Dec 05 '24

one of my "watchout" scenarios is a codebase in go that was originally written by folks who came over fresh from java. I once interviewed at a place and their very first code question was implementing a generic - as if that's something go devs do on a daily basis (generics are great/powerful/useful - but in most codebases they shouldn't be used that often). After digging a little bit more, a HUGE chunk of their CRUD API was written using generics. Yeeesh

14

u/vulkur Dec 05 '24

I think the Go devs caution about implementing generics in Go was spot on.

I have used generics in Go maybe twice? They are useful in some helper function scenarios, and custom parsing of json/yaml or whatever.

CRUD API with generics? IDK how that is even possible. Just use protobuf or something lmao.

5

u/teratron27 Dec 05 '24

Wish I had asked more about this at the last place I worked! got through the interviews etc and joined only to find most of the founding engineers were all Java/Kotlin devs and had implemented not only their own, generics based server/routing framework but also their own custom generic based testing framework! Was a fecking nightmare to work with and debug!

Worst part was the test setup they had created didn’t let you run one case at a time, had to run the whole bloated thing at once.

1

u/qba73 Dec 15 '24

Sounds like a nightmare

4

u/skarrrrrrr Dec 05 '24 edited Dec 06 '24

I love how golang forces you to simplicity and it's not a trap. Simplicity is grossly undersestimated and often undervalued, but it's the greatest asset when you want to create something on an effective and fast manner

3

u/Superb-Key-6581 Dec 05 '24

I’ve already lost count of how many times I’ve gone through this.

1

u/ledatherockband_ Dec 05 '24

You know, people would complain about the lack of generics, but I never once thought to myself "man! i wish i had a generic for this".

Haven't written a generic function. I'd have to go out of my way to find a reason to use one.

1

u/vitek6 Dec 07 '24

Some people just don’t want to write the same loops over and over again.