En términos simples, un bus de servicio es un mecanismo para intercambiar mensajes entre componentes. Los mensajes son DTOs (Data Transfer Object / Objectos de transferencia de datos) que contienen información relevante que nos permite interactuar sobre dicha información.

Existe un componente conocido como “emisor” cuya responsabilidad es la creación del mensaje y su entrega al bus. Por otro lado, existe un segundo componente conocido como “receptor” que le especifica al bus qué tipo de mensajes le interesa recibir.

Cuando el bus recibe un mensaje, envía el mensaje a los receptores, entonces, en realidad el bus actúa como el límite entre los distintos componentes creando desacoplamiento en nuestra solución de software. Tanto los emisores, como los receptores, desconocen la existencia de otros componentes.

Debido a este desacoplamiento, un bus de servicio puede permitir que diferentes componentes trabajen juntos de manera eficiente. Dado que el bus se encuentra en el intermedio de todos los mensajes, puede agregar funcionalidad a todos estos mensajes sin cambiarlos. Un ejemplo puede ser el registros de todos los mensajes en un sistema de logs o su encolamiento en una cola de mensajes.

Tipos de bus

En los párrafos anteriores se describió un bus de servicio de maneral general, un bus que únicamente despacha mensajes. No restringe a los mensajes o a los manejadores de mensajes de manera alguna.

Es normal que distintos tipos de mensajes requieran distinta lógica gestión, es por ello que se puede hablar de tipos de bus y hoy me interesa comentar sobre los siguientes tres:

Bus de comandos

Se caracteriza por:

• Los mensajes (comandos) señalan la intención del usuario, por ejemplo: CrearSolicitud o RegistrarUsuario
• Un comando es manejado por exactamente un controlador (handler)
• Un comando no retorna valor alguno.

Bus de consultas

En ingles conocido como Query bus, se caracteriza por:

• Los mensajes (consultas / queries) identifican una pregunta, que no está relacionada necesariamente con una consulta a base de datos (sql query). Algunos ejemplos serían: UltimasSolicitudes o ComentariosDeUnArticulo
• Una consulta es manejada por exactamente un controlador (handler)
• Las consultas retornan datos
• Las consultas no deben cambiar el estado de la aplicación

Bus de eventos

Un bus de eventos se caracteriza por:

• Los mensajes (eventos) indican que ha sucedido un evento, como por ejemplo: ArticuloCreado. UsuarioRegistrado o SolicitudFormalizada
• Un evento puede ser manejado por cualquier numero de controladores / handlers ([0, inf])
• Solo contiene un conjunto de valores primitivos (cadenas de texto, enteros, booleanos), no clases completas.
• Los eventos no deben devolver valores

Consideraciones importantes

Validaciones

Los mensajes siempre deben ser válidos. Esto significa que el objeto / estructura que contiene el mensaje debe validar cada una de sus propiedades. De esta forma, solo se despachan mensajes válidos. Sin embargo, hay un límite para esto.

Por ejemplo, el comando RegistrarUsuario puede requerir (entre otras cosas) un nombre de usuario. El comando debe validar que el nombre de usuario sea una cadena de texto con una longitud entre 6 y 100 caracteres. Si el nombre de usuario es único o no, probablemente no debería ser validado por el comando y quien asumirá dicha responsabilidad es el controlador (handler)

Patrones de diseño

La implementación de comandos y consultas es parte (commands & queries) son parte del patrón CQRS. Sin embargo se puede utilizar buses de servicio sin aplicar CQRS.

Los comandos y eventos a menudo se utilizan juntos, entonces, cuando se ejecuta el comando RegistrarUsuario se activa el evento UsuarioRegistrado.