¿Está bien diseñada esta arquitectura hexagonal para un microservicio de pagos?

Fitness

¡Hola Hackmates! Estoy trabajando en un microservicio de pagos y he optado por una arquitectura hexagonal (puertos y adaptadores). La idea es que el núcleo (dominio) no dependa de nada externo. He separado en tres módulos: domain (entidades, repositorios como interfaces), application (casos de uso) e infrastructure (implementaciones de repositorios, controladores REST, etc.).

Mi duda principal: en el caso de uso ProcessPaymentUseCase, necesito llamar a un servicio externo de pasarela de pago (Stripe, por ejemplo). He creado un puerto (interfaz) PaymentGateway en domain, y su implementación en infrastructure. Pero siento que el caso de uso se vuelve anémico si solo orquesta llamadas. ¿Es correcto o debería poner lógica de negocio (como validaciones de monto, comisiones) dentro del caso de uso?

Además, para manejar errores de la pasarela, estoy usando excepciones propias del dominio. ¿Algún consejo sobre cómo estructurar mejor esto? ¡Gracias!

Photographer

Buena pregunta. La arquitectura hexagonal es ideal para microservicios. Respecto a tu duda: el caso de uso no debería ser anémico, pero tampoco debe contener lógica de negocio que pertenezca a las entidades. Por ejemplo, validar que el monto sea positivo es responsabilidad de la entidad Payment. El caso de uso solo orquesta: llama al repositorio para guardar, al gateway para procesar, y aplica reglas de negocio como calcular comisiones (si son reglas de aplicación). Las excepciones de dominio están bien, pero asegúrate de que no sean demasiado genéricas. Yo usaría PaymentException y subtipos.

Piano

No estoy de acuerdo del todo. En mi experiencia, poner lógica de comisiones en el caso de uso puede llevar a duplicación si otro caso de uso necesita calcularlas. Yo crearía un servicio de dominio FeeCalculator (entidad o value object) y lo inyectaría en el caso de uso. Así el dominio es rico y el caso de uso sigue siendo delgado. Sobre el gateway, ¿estás usando un patrón como Circuit Breaker? Si no, podrías considerar envolver la llamada en un adaptador que lo implemente.

Fitness

¡Gracias por las respuestas! Me gusta la idea del FeeCalculator como servicio de dominio. Creo que lo moveré allí. Sobre el Circuit Breaker, lo tengo pendiente, pero primero quiero asegurar la estructura base. Otra cosa: ¿cómo manejan la transacción entre guardar el pago en BD y llamar al gateway? Por ahora lo hago en el caso de uso, pero si falla el gateway, el pago queda como 'pendiente'. ¿Alguna recomendación?

Audiobooks

Para la transacción, puedes usar un patrón Saga o eventos de dominio. Por ejemplo, al crear el pago emites un evento PaymentCreated y un manejador asíncrono intenta procesar el gateway. Si falla, emites PaymentFailed y actualizas el estado. Así evitas transacciones distribuidas. Eso sí, necesitas un bus de eventos en infrastructure.

Hiking

Ojo con las sagas: añaden complejidad. Para un microservicio pequeño, podrías simplemente usar un outbox pattern y un worker que reintente. Pero si el dominio es crítico, eventos de dominio con eventual consistency está bien. También revisa que tu repositorio de pagos permita actualizar estado atómicamente.

Fitness

Muy buenos puntos. Creo que implementaré el outbox pattern para no complicar demasiado. Y lo del FeeCalculator lo pongo ya en domain. ¡Gracias a todos por la ayuda! Me queda mucho más claro.

Typography

Un detalle más: asegúrate de que las interfaces en domain (puertos) sean cohesivas. Por ejemplo, PaymentGateway no debería tener métodos como sendEmail. Y si usas excepciones de dominio, captúralas en la capa de application y conviértelas a respuestas HTTP con el código adecuado (ej. 400 para validación, 503 para gateway caído). ¡Suerte!