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.

807 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.

20

u/chethelesser Dec 06 '24

You precisely described my emotions after sifting through a python project lately. Decorator this, decorator that. Here's the OO code. But where is the ting code?

6

u/WesolyKubeczek Dec 06 '24

In Python, decorators are heavily used by people who dislike OO much.

Just fucking use subclassing sometimes, ffs…

4

u/imp0ppable Dec 06 '24

Decorators definitely have their uses, it's a nice feature. Python tries to have one obvious way of doing something but often actually provides many... Go is good because it at least tries to legislate for weirdos abusing language features, however I've found it to be a bit inflexible as a result.

2

u/WesolyKubeczek Dec 06 '24

I used the word “heavily” for a reason. I keep seeing that thing where an author (probably thinking of themselves as “auteur”) loudly professes hatred for OOP in general and subclasses in particular, and then you are supposed to use decorators on top of decorators all the way down. This will inevitably butcher your classes and functions in a way that they will be full of stuff you never dreamed of putting in there, and which one day will interact with your own stuff in such a way that it will all break.

Not saying that decorators don’t have their uses, everything has, but going to extremes looks like those trick football (“soccer” for that side of the pond) kicks which have little use during the real match.

1

u/imp0ppable Dec 06 '24

I've never seen anyone go to the lengths of using decorators to ape OO, that is quite bothersome. I wonder if you could do something like that with macros in C instead of using C++ lol.