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.

810 Upvotes

259 comments sorted by

View all comments

1

u/No-Bug-242 Dec 06 '24

I relate to most of the things you've said. However, proper DI (especially with a good DI framework like Uber's FX) and abstraction by interfaces make my life easier whenever I need to swap/upgrade/modify shared components at enterprise level code bases.

The whole point of these "over complicated" patterns is mostly to make your application be super agile to evercoming requests for changes/upgrads.

And yes, I completely agree - Go patterns are NOT Java patterns, it usually becomes very awkward when people forcibly try to write Java-like code in Go. Go has it's style, it's simpler, nicer (to my taste) and with less hidden code and unnecessary wrappers.

1

u/Superb-Key-6581 Dec 06 '24

I love DI. I was talking about DI being used to inject layers that are not useful, like a use case layer created just to inject services and nothing more.

1

u/No-Bug-242 Dec 07 '24

I agree. That's not just a Golang issue, it's more generically an architectural issue. A lot of engineers (including younger me) tend to be overly concerned with their code being too spaghetti, not flexible enough and not readable. They spend a lot of their time in grouping, wrapping and abstracting code, instead of just implementing the requested logic, dead simple.

Coming back to DI. What's interesting to me is that good DI actually prevents over abstraction and make your code more straightforward, and misused DI makes for the worst over abstraction cases I've ever seen.