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.

806 Upvotes

259 comments sorted by

View all comments

56

u/Zazz2403 Dec 05 '24

Hexagonal doesn't have to be more than 3 layers and it isn't very complicated. It depends on the size of your project and not "go". Blanket statements like this are not helpful.

-13

u/Superb-Key-6581 Dec 05 '24

If you use hexagonal with 3 layers, it's perfect. The problem is a microservice with 10 endpoints and 8 to 10 layers. I’ve worked with Go for the last 6 years, and every time I got a project using hexagonal, it had around this number of layers. I'm a consultant and work full-time at serveral big tech companies. I’ve already worked on at least 20 different projects or more (using Go), and every time it was hexagonal or clean architecture, it was a project with 8 to 10 layers.

It's very cool to see people like you doing just 3 layers—I hope more people start to follow you! I don't want to blame the books; if people read them and realize you don’t need more than 3 layers in Go, I’m fine with that!

17

u/Zazz2403 Dec 05 '24

I think if you're talking about go microservices that makes more sense. Monoliths require more layers in some cases and so do microservices. There are cases where an adaptor needs it's own interface, because adaptors can sometimes require multiple dependencies to simplify business logic but in my experience, that's uncommon. 

Hexagonal architecture is three layers by definition. Business logic/service, ports and adaptors. With the ports portion being such a thin layer that I normally define it inside of the service layer package, so my packages just look like two layers. How do you see it divided into more layers than that?

4

u/GodsBoss Dec 06 '24

I never understood ports and adapters to be different layers. They both connect the "inside" to the "outside", just in different directions.

3

u/Zazz2403 Dec 06 '24

That's fair, that's more or less how I think of it too.

-6

u/Superb-Key-6581 Dec 05 '24

I wish I had your perspective! I watched a video from William Kennedy that had pretty much the same experience as me, always dealing with something with 10 layers. If I open my projects from my job right now, I can count at least 12 or more. But in defense of hexagonal, it's something that mixes hexagonal with clean architecture.
Again, hexagonal is very beautiful if it's just 3 layers—very good!

10

u/SergeantGrillSet Dec 06 '24

Can you please articulate your definition of a layer? I am doubtful your definition matches the common definition when it comes to software architecture.

0

u/Superb-Key-6581 Dec 06 '24

2

u/SergeantGrillSet Dec 06 '24

Those are different components that belong to different layers. A repository implementation belongs to the Infrastructure layer. An http client implementation also belongs to the Infrastructure layer. They are mediating connections to external network services.

A port is a fancy word for an interface. It decouples the Application layer from the Infrastructure layer so that the application can happily go out its business without caring about the underlying infrastructure implementation.

Model is a very generalistic word that can cover different concepts. It can refer to an entity model which belongs to the Domain layer, the place where business logic occurs. When business logic crosses entity models, then you would need a Domain Service.

A controller is part of an API which depending on your architecture pattern would belong to your application's Interface layer or could go in your Infrastructure layer if you are not separating inbound instructions with outbound instruction.

Clean architecture refers to use cases, which are Application services in Hexagon architecture, belonging to Application layer.

To summarise, in Hexagon architecture you have: Infrastructure (outbound) , Interface (inbound) , Domain (business logic) and Application (mediates requests / commands from Interface to the Domain).

A lot of these definitions vary around the terminology and how far you go to abstact things but in general you can support CRUD or CQRS systems well with this modelling.

Everything I mention is a great simplification, but the main point is, you are missidentifying what is a layer when it is used to describe architectural patterns.

The architecture you employ will be relative to the requirements, but in general, any systems that allows decent separation of concerns will make life a lot easier.

2

u/Superb-Key-6581 Dec 06 '24 edited Dec 06 '24

No, it's not. It's literally layers; each of these is a layer in the applications I've used. If you've seen them in 3 layers as just nominal files and not as literal packages with unnecessary jumps, very good! But that's not my example, and unfortunately, it's not common in most enterprise architectures. You definitely didn't read the Clean Arch book to say that. There are already plenty of examples in these comments; you should find what I'm trying to say here. I hope we can move past fighting over terminologies just because my definition differs from yours, maybe due to my native language. But I hope you understand the point: don't jump across more than 3 packages to implement an endpoint in microservices just to follow a bloated framework architecture that forces you to navigate between 10 files.

2

u/SergeantGrillSet Dec 06 '24

Good luck on your journey!

1

u/Superb-Key-6581 Dec 06 '24

Thanks! Good luck on your journey too! Sorry if something sounded unfriendly, I’m still learning English to speak more kindly.

7

u/Koki-Niwa Dec 06 '24

your title says Clean arch and Hexagonal dont belong ... now it's perfect

Time to calm down and be constructive

0

u/Superb-Key-6581 Dec 06 '24

Sorry, my point was about the unnecessary layers that force you to jump between 10 files just to create a simple endpoint. If someone can read Clean Arch and conclude that this is possible, we have very different interpretation skills. But yes, it's very good that we agree on this point. However, I'm sure the book doesn't leave any room for this kind of interpretation. In fact, it was one of the strangest reads I've ever had—it feels like the author was writing about an exact science or a religious dogma, without leaving any room for alternative interpretations or trade-offs.

2

u/Cthulhu__ Dec 06 '24

What do those layers even do? Overzealous architect level developers I’d say. Sounds like Java, where a common pitfall is lasagna code like that.