Arquitectura hexagonal en Go: ¿Me estoy pasando con las interfaces?

Cars

¡Hola comunidad! Estoy armando un microservicio en Go con arquitectura hexagonal/ports & adapters. La idea es que sea mantenible y testeable, pero siento que estoy abusando de las interfaces y la cosa se vuelve verbosa. Les dejo un snippet de cómo estoy definiendo el repositorio y el caso de uso:

type UserRepository interface {
    Save(ctx context.Context, user *User) error
    FindByID(ctx context.Context, id string) (*User, error)
    FindByEmail(ctx context.Context, email string) (*User, error)
    Update(ctx context.Context, user *User) error
    Delete(ctx context.Context, id string) error
}

type UserService struct {
    repo UserRepository
    emailService EmailSender
}

¿Creen que es mejor tener interfaces más pequeñas o una sola interfaz grande? También me gustaría saber si ven alguna otra red flag en la arquitectura. ¡Gracias!

Vinyl

¡Buenas! Entiendo tu preocupación. Personalmente prefiero interfaces más específicas, tipo UserReader y UserWriter, para seguir el principio de segregación de interfaces (ISP). Así cada componente sólo depende de lo que necesita. Además, en Go es común tener interfaces pequeñas. Por ejemplo, un handler HTTP que solo lee usuarios no debería necesitar el método Delete. ¡Suerte!

Cars

Gracias por la respuesta. Tiene sentido lo de separar lectura y escritura. ¿Pero no se vuelve un infierno de archivos? Igual voy a probar ese enfoque a ver si mejora la claridad. También me preocupa el tema de los tests, con interfaces grandes es más fácil mockear todo de un saque, ¿no?

Sewing

Concuerdo con que interfaces pequeñas es mejor, pero con cuidado. A veces se exageran y terminan con interfaces de un solo método que no aportan mucho. En tu caso, UserRepository me parece bien si todos los métodos se usan siempre juntos. Lo que sí, fíjate que UserService depende de EmailSender aparte. Ahí podrías tener una interfaz separada. Sobre los tests: en Go, los mocks se generan fácil con mockgen o escribiéndolos a mano. No es problema.

Surfing

Ojo con el context.Context en todos los métodos: es correcto, pero asegúrate de propagarlo bien. También, ¿has considerado usar un patrón repositorio con un solo método genérico Find que acepte filtros? Algo como Find(ctx, filter map[string]interface{}). Eso reduce la interfaz a 2-3 métodos. Eso sí, pierdes tipado fuerte.

Cars

Lo de los filtros genéricos me da un poco de yuyu porque pierdes la seguridad del compilador. Pero para ciertos casos podría valer la pena. Al final voy a dividir el repositorio en dos interfaces: una de solo lectura y otra de escritura. ¡Gracias a todos por los consejos! Voy a refactorizar y si sale algo interesante lo comparto.

Piano

Si te sirve de inspiración, en el proyecto en el que trabajo usamos algo parecido pero con interfaces funcionales (opciones). Por ejemplo, el repositorio expone WithUserReader() y WithUserWriter() como opciones de configuración del servicio. Eso permite tener un solo constructor y ir armando el servicio según necesidades. No es muy común pero funciona.

Reggae

Las interfaces funcionales molan, pero cuidado con acoplar la configuración a la inyección de dependencias. Prefiero mil veces tener interfaces explícitas aunque sean muchas, porque el día que necesites mockear para tests, agradeces no tener que construir un servicio con opciones solo para cambiar un repo. Además, con Go 1.18+ puedes usar genéricos para reducir interfaces de repositorio sin perder tipado: type Repository[T any] interface { Find(ctx context.Context, id string) (T, error); Save(ctx context.Context, entity T) error }. Así tienes una interfaz por entidad, no por operación, y mantienes la seguridad. ¿Alguien ha probado este enfoque en producción?

Standup

Los genéricos ayudan, pero cuidado con el acoplamiento: un repositorio genérico asume que todas las entidades se comportan igual (misma clave, mismo CRUD). En proyectos grandes, eso se rompe rápido. Prefiero interfaces específicas aunque sean muchas, porque el compilador te obliga a implementar solo lo necesario. Eso sí, para CRUDs simples los genéricos van de lujo. ¿Has tenido problemas con métodos que no aplican a ciertas entidades? Por ejemplo, un repo de solo lectura con Find pero sin Save.

Cocktails

El problema de los genéricos para repositorios es que asumen un modelo de datos homogéneo. En la práctica, cada agregado tiene sus propias reglas de persistencia. Yo prefiero interfaces pequeñas segregadas: un UserReader y un UserWriter separados. Para tests, puedes mockear solo lo que necesitas sin arrastrar dependencias que no tocan. Y si te preocupa la cantidad de interfaces, en Go las interfaces implícitas permiten definir el contrato justo donde se consume, sin inflar el paquete de dominio. El truco está en poner las interfaces en el lado del consumidor, no del productor. Así el repositorio solo exporta structs concretos y el adaptador primario define lo que necesita. ¿Alguien ha probado a generar las interfaces de servicio a partir de los casos de uso con stringer o similar?