The talking list

Derek Comartin tiene este blog y canal de Youtube en el que trata numerosos temas relacionados con el diseño y arquitectura de software con una aproximación crítica, dedicando muchos posts y vídeos al tema de las arquitecturas Event-Driven, pero también a cuestiones más básicas de diseño. Creo que no hay ni un solo vídeo que no quiera ver en algún momento.

Realmente me parece un canal que merece la pena seguir, aunque hay que tener cuidado de no engancharse porque son decenas de tamas interesantísimos y más allá de que puedas estar de acuerdo en todos sus argumentos, la presentación es muy buena y te hace reflexionar.

A great example of this is Domain-Driven Design. When people first get into it, they immediately latch on to the tactical patterns in code such as Entities, Value Objects, Aggregates, etc. You can find all kinds of tutorials that show you how to use these patterns, but rarely do they ever explain the reasons why you might use them and where they might not be useful. The moral of the story is that you’ll be better served focusing on the problem at hand and the use cases. Then determine what technical solution fits.

Code Opinion

No pasa un día en que no me encuentre con un post, un vídeo o un comentario en alguna red en la que alguien diga algo así como: “en mi equipo estamos haciendo arquitectura hexagonal y tenemos la capa de dominio, la de aplicación y la de infraestructura”.

Pues no. No estáis haciendo arquitectura hexagonal. Eso que mencionas es una arquitectura de tres capas que recoge conceptos comunes de las arquitecturas limpias:

• El dominio está aislado del mundo real y define abstracciones para no depender de tecnologías concretas.
• Los casos de usos coordinan los elementos del dominio para ejecutar las finalidades de la aplicación y viven en una capa que puede tener ese nombre.
• Los detalles de implementación de las abstracciones del dominio viven en una capa de infraestructura.
• Las dependencias siempre apuntan al dominio, que es como decir, que todo depende del dominio y el dominio no depende de nada más.

¡Ojo!, no estoy diciendo que eso esté mal. De hecho, si lo estás haciendo así, en realidad está muy bien. Es solo que eso no se llama arquitectura hexagonal. Si hablas de arquitectura hexagonal háblame de puertos y háblame de adaptadores. Pero no de capas, aunque puedes organizar tu aplicación en capas si así te viene bien.

Y no es por ser pejiguero. Pero usar la terminología con precisión es un deber profesional. De otro modo, no podemos comunicarnos eficazmente.

Es raro el equipo de desarrollo que no diga que está haciendo Arquitectura Hexagonal en sus proyectos. Es raro el equipo de desarrollo que la esté haciendo realmente.

No, Domain-Application-Infrastructure no es arquitectura hexagonal

Siempre acabo volviendo a este artículo de Mathias Verraes en el que explica brevemente los diferentes tipos de mensajes con los que pueden comunicarse las aplicaciones.

A message is a unit of communication between systems. There are three flavours of messages: informational, interrogatory, and imperative.

Messaging Flavours