Hexagonal Architecture and interface pollution

I am in a project working with an implementation of the Port & Adapters concept in its canonical version, we only have 3 layers: models (entities, DTOs, etc), domain (business logic), infra (handlers, postgres).

But, in domain we have many fat interfaces including methods with long names that can actually be helpers, that has given me a bad development experience (DX) because those interfaces must be implemented and it is like unnecessary bureaucracy or preventive abstraction.

Is this traditional approach of Hexagonal Architecture in Go correct? I have a year of exp in Go.

1 Like

Hi @adrianolmedo,

Fat interfaces are Java-ish. I don’t think that Hexagonal Architecture (HA) requires interfaces to be fat. HA is about separation of concerns, so as long as you achieve that goal, you should be ok. Hence I see no problem with using HA with Go. The problem seems to be more about how to make the interfaces more Go-ish (that is, break them into smaller ones where possible).

2 Likes