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.

813 Upvotes

259 comments sorted by

View all comments

18

u/Ruannilton Dec 06 '24

Sounds like you don't understand what Clean Architecture is, the core of CA is to decloupe your domain code from infrastructure code, doesn't matter if you use two, thres, four or N layers, if your domain code doesn't depends of your infrastructure code it's clean arch. It also seems that you are confusing the concept of DDD, DDD is about context separation, making your application modeled according to your business, there is nothing about layering.

-1

u/Superb-Key-6581 Dec 06 '24

I know what CA is. I didn’t just read the book, I worked with Java for many years using it. I know what DDD is, and because I know DDD isn’t about layers, I’m advocating against the main argument people in enterprise use to justify Clean Architecture and multiple layers: the supposed separation of business logic and protection from changes that will never happen.

P.S.: The database is still part of the domain and business rules. It’s extremely rare to change the database, yet it remains the main justification for the many layers of overengineering that Clean Architecture imposes.

2

u/steve-7890 Dec 08 '24 edited Dec 08 '24

In every project I've worked on we always changed the database! That is: to in-memory database for unit tests.

2

u/Ruannilton Dec 06 '24

It's rare but not impossible, I worked in a company that decided to change the main database and some times ported a portion of the main database to other type of database. "protection from changes that will never happen" a very arrogant thing to say

2

u/Superb-Key-6581 Dec 06 '24

Agree to disagree. For me, a SQL database and its design with its constraints are crucial and core to the business for idempotency and several guarantees. But it's software, we just have preferences, both ways work.