Support for multiple MQs, Rabbit, Google PUBSUB, etc... about commanded HOT 8 CLOSED

What's the use case for supporting multiple message queues?

A consumer of Commanded can write an event handler that pushes events straight onto any message queue they choose to use. It doesn't require explicit support, it's provided by the event store.

from commanded.

Maybe a "one point" contract adapter, like: https://github.com/ChicagoBoss/ChicagoBoss/blob/master/src/boss/mq_adapters/boss_mq_adapter_tinymq.erl

from commanded.

I'm still unsure what you want to use it for, and why it needs to be implemented here?

from commanded.

I thought that if we could generalize the MQ in a behavior (or plugin), easily one could migrate from one MQ to another. Example, the registry sends one command using point-to-point pattern to aggregate instance; An abstract layer between this communication could easy the user to use Rabbit MQ, or other. Also with event messages, one could 'subscribe' to this abstract layer, and easily use Rabbit to queue messages and process them, instead of using the eventstore. Maybe I should study better Commanded and it's an idea "out of the bounded context"

from commanded.

I only find this useful to integrate with legacy code.

from commanded.

or to delegate at-least-once deliver and de-duplication...https://github.com/pawelkaczor/akka-ddd/wiki/Reliable-Delivery

from commanded.

Why a queue here?
EventStore, for example, can already serve the needs of pub/sub for at-least-once-at-most-once requirements.
For other stuff, I say write a projection that will push stuff to a queue.

I quite like the smallness and speciality of this library. Don't want to see it bloated.

from commanded.

Closing this issue. You can use an event handler to push events onto whichever message bus you like.

from commanded.