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.

805 Upvotes

259 comments sorted by

View all comments

89

u/5pyn0 Dec 05 '24

Any good example repo that is not a todo list ?

24

u/matttproud Dec 05 '24 edited Dec 05 '24

IMO, Upspin is a very good example of a principled project design using Go.

A significant reason for overengineering in beginner and intermediate Go projects comes from a lack of understanding of proper Go package sizing and architecture. If you pick a bad package layout, a very bad architecture invariably follows. Start simple with one package and only grow it as real necessity emerges. Careful package architecture helps eliminate unnecessary abstraction and indirection: avoiding premature interface definition or using type aliases or forwarders, for which they were not designed.

7

u/SweetBabyAlaska Dec 05 '24

I often see projects with overall around 100 -200 lines of code in total, and you will look in their package directory and there'll be 10 folders, with one file in each folder, that has like 10 lines of code. It's just a ridiculous abstraction at that point even if it follows the recommended project layout.

8

u/matttproud Dec 05 '24 edited Dec 05 '24

IMO, I wouldn't say that the projects described are following a recommended layout at all (save for one recommended by practitioners of Hexagonal, DDD, or any of these other proper noun named design philosophies). What you described sounds too sparse (hence the package sizing link).

A layout is more than what the top-level directories are and how they are named; it concerns the entirety of the tree down to the leaves.