Eu tenho algumas coisas que gostaria de destacar:
- Eu me referiria a comandos em vez de operações . Isso se encaixa na linguagem em torno do sistema que você está modelando melhor, eu acho.
- Parece que você está usando os eventos como um acionador para recuperar dados de outros serviços. Você também usará os eventos para criar essas entidades? Se for esse o caso, sugiro strongmente que introduza alguma forma de EventStore para cada aplicativo para armazenar os eventos nos quais você está publicando. Você pode então reutilizar esses eventos para recriar suas entidades, se necessário. A maioria das pessoas se refere a isso como Sourcing de Eventos, embora eu prefira usar esse termo para o lado da gravação (o 'tratamento de operação' no seu exemplo) do aplicativo. No entanto, eu criaria suas entidades nesses eventos também. Se você adotasse essa abordagem, poderia até permitir que os outros serviços ouvissem todos esses eventos e criassem a entidade necessária, o que omitiria a necessidade de consultar as entidades.
- Você indica que adicionará outro serviço para auditoria. Se você seguir minha sugestão do ponto 2, sua loja de eventos também será automaticamente seu log de auditoria. Obviamente, isso só será válido se você modelar seus eventos corretamente, mas, no entanto, acho que tornar seus eventos cidadãos de primeira classe e armazená-los imediatamente após a publicação omite a necessidade de um serviço de log de auditoria dedicado.
- Sem saber em que linguagem de programação você está, sugiro ainda dar uma olhada em alguns frameworks CQRS / EDA / DDD, como o Axon Framework por exemplo. É baseado em Java, mas mesmo se você não estiver em Java, os conceitos que o framework tenta ajudá-lo se parecem com o que você está tentando fazer.
Em suma, acho que remodelar seu aplicativo como algo que é uma sugestão é uma coisa boa. Tornar a sua mensagem de comunicação baseada e a localização dos seus serviços transparente garante que você perca o acoplamento com o qual está preocupado neste momento.