As mensagens assíncronas (em particular as mensagens de estilo pub/sub) são viáveis ​​como uma arquitetura de serviço de domínio ou apenas em um ambiente focado em SOA?

Question

Tenho pesquisado mensagens assíncronas e gosto da maneira como elas lidam com elegância com alguns problemas em determinados domínios e como tornam os conceitos de domínio mais explícitos.Mas é um padrão viável para o desenvolvimento geral orientado por domínio (pelo menos na camada de serviço/aplicação/controlador), ou a sobrecarga de design é tal que deveria ser restrita a cenários baseados em SOA, como serviços remotos e processamento distribuído?

Answer 1

Ótima pergunta :).O principal problema com mensagens assíncronas é que quando as pessoas usam linguagens procedurais ou orientadas a objetos, trabalhar de maneira assíncrona ou baseada em eventos costuma ser bastante complicado, complexo e difícil para o programador ler e entender.A lógica de negócios geralmente é muito mais simples se for construída de maneira síncrona - invocando métodos e obtendo resultados imediatamente, etc :).

Minha regra geral é tentar usar modelos de programação síncrona mais simples no nível micro para lógica de negócios;em seguida, use assincronia e SEDA no nível macro.

Por exemplo, enviar um pedido de compra pode simplesmente escrever uma mensagem em uma fila de mensagens;mas o processamento do pedido de compra pode exigir 10 etapas diferentes, todas assíncronas e paralelas em um sistema distribuído de alto desempenho com muitos processos e threads simultâneos processando etapas individuais em paralelo.Portanto, a fiação no nível macro é baseada em uma abordagem do tipo SEDA - mas no nível micro, o código para as 10 etapas individuais pode ser escrito principalmente em um estilo de programação síncrona.

Answer 2

Como tantas questões de arquitetura e design, a resposta é “depende”.

Na minha experiência, a força das mensagens assíncronas está no baixo acoplamento que elas trazem para um design.O acoplamento pode ser em:

• Tempo – As solicitações podem ser tratadas de forma assíncrona, ajudando na escalabilidade geral.
• Espaço - Como você destacou, permite o processamento distribuído de maneira mais robusta do que muitos designs síncronos.
• Tecnologia - Mensagens e filas são uma forma de superar as diferenças tecnológicas.

Lembre-se de que mensagens e filas são uma abstração que pode ter diversas implementações.Você não precisa necessariamente usar uma estrutura de mensagens transacional, de alto desempenho e compatível com JMS.Implementada corretamente, uma tabela em um banco de dados relacional pode atuar como uma fila com as linhas como mensagens.Já vi ambas as abordagens usadas com grande efeito.

Answer 3

Eu concordo com @BradS também, aliás

POR FALAR NISSO aqui está uma maneira de ocultar o middleware da sua lógica de negócios enquanto ainda obtém os benefícios do acoplamento flexível e SEDA - ao mesmo tempo em que é capaz de alternar facilmente entre uma variedade de diferentes tecnologias de middleware - de SEDA na memória para JMS, para AMQP, para JavaSpaces, para banco de dados, arquivos ou FTP, etc.