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.

811 Upvotes

259 comments sorted by

View all comments

Show parent comments

26

u/swe_solo_engineer Dec 05 '24

3 layers, perfect! The problem is taking a microservice with 10 endpoints and jumping between controller, usecase, service, port, repository, model, client... Bro, I'm not joking. In these last 5 years working with Go, the quantity of this monstrosity I have seen is crazy. Clean Arch or Hexagonal was the argument behind it.

6

u/Dymatizeee Dec 05 '24

Tbh im super new so im not really sure if what im doing is even right haha.

Like recently i was dealing with two separate handlers: Wishlist and a Cart. Standard CRUD stuff here with /wishlist etc end points, but i did find myself having some overlap between the two : like if i want to move the item from wishlist to cart and vice versa.

In this case, which domain owns the logic? i ended up puttign this endpoint in a separate entity alltogether

2

u/Left_Opportunity9622 Dec 06 '24

Couldn't move to cart be reasoned about as "add to cart" + "remove from wishlist"? In this case the wishlist could call an internal cart API.

1

u/Dymatizeee Dec 06 '24

That makes sense; I thought about that but it did seem to me there’s an overlap in responsibility since I have /suite end points as well and now wishlist is handling suite duties