¿Es la mensajería asíncrona (en particular la mensajería de estilo pub/sub) viable como arquitectura de servicio de dominio o sólo en un entorno centrado en SOA?

Question

He estado investigando la mensajería asincrónica y me gusta la forma elegante en que aborda algunos problemas dentro de ciertos dominios y cómo hace que los conceptos de dominio sean más explícitos.Pero, ¿es un patrón viable para el desarrollo general impulsado por el dominio (al menos en la capa de servicio/aplicación/controlador), o la sobrecarga de diseño es tal que debería restringirse a escenarios basados ​​en SOA, como servicios remotos y procesamiento distribuido?

Answer 1

Gran pregunta :).El principal problema con la mensajería asincrónica es que cuando la gente usa lenguajes procedimentales u orientados a objetos, trabajar de manera asincrónica o basada en eventos suele ser bastante complicado, complejo y difícil de leer y comprender para el programador.La lógica empresarial suele ser mucho más sencilla si se construye de forma algo sincrónica: invocando métodos y obteniendo resultados inmediatamente, etc. :).

Mi regla general es intentar utilizar modelos de programación sincrónica más simples a nivel micro para la lógica empresarial;luego use asincronía y SEDA a nivel macro.

Por ejemplo, enviar una orden de compra podría simplemente escribir un mensaje en una cola de mensajes;pero el procesamiento de la orden de compra puede requerir 10 pasos diferentes, todos asincrónicos y paralelos en un sistema distribuido de alto rendimiento con muchos procesos y subprocesos simultáneos que procesan pasos individuales en paralelo.Entonces, el cableado del nivel macro se basa en un enfoque tipo SEDA, pero en el nivel micro, el código para los 10 pasos individuales podría escribirse principalmente en un estilo de programación sincrónica.

Answer 2

Como tantas preguntas sobre arquitectura y diseño, la respuesta es "depende".

En mi experiencia, la fortaleza de la mensajería asincrónica ha estado en el débil acoplamiento que aporta al diseño.El acoplamiento puede ser en:

• Tiempo: las solicitudes se pueden manejar de forma asincrónica, lo que contribuye a la escalabilidad general.
• Espacio: como usted señala, permite el procesamiento distribuido de una manera más sólida que muchos diseños sincrónicos.
• Tecnología: los mensajes y las colas son una forma de salvar las diferencias tecnológicas.

Recuerde que los mensajes y las colas son una abstracción que puede tener diversas implementaciones.No es necesario utilizar necesariamente un marco de mensajería transaccional de alto rendimiento compatible con JMS.Implementada correctamente, una tabla en una base de datos relacional puede actuar como una cola con las filas como mensajes.He visto ambos enfoques utilizados con gran efecto.

Answer 3

También estoy de acuerdo con @BradS, por cierto.

POR CIERTO Aquí tienes una forma de ocultar el middleware de tu lógica empresarial. sin dejar de obtener los beneficios del acoplamiento flexible y SEDA, y al mismo tiempo poder cambiar fácilmente entre una variedad de tecnologías de middleware diferentes, desde SEDA en memoria a JMS, AMQP, JavaSpaces, bases de datos, archivos o FTP, etc.