A ServiceBus Or MessageBroker

What is a Service Bus and a Message Broker?

Like can be gathered from the previous pages, the DDD/CQRS architecture revolves a lot about temporal decoupling to archive the availability and partitionability properties required for scaling and building occasionally connected systems. We realize this by having a queue-based architecture.

The other way, the default way for most programmers, would be RPC-style request-reply while blocking the thread-type of communication that requires systems which we are calling, to be available.

When point to point communications aren't scaling

Point to point communications don't scale in the same manner as queues do. A durable queue in RabbitMQ would save messages for the consumer, even if that consumer is temporarily offline.

However, if the messages are only relevant if they can be received instantaneously, then it could be wise to implement the broadcast with a transport-level mechanism rather than an application-level such - for example by using IPv6 multicasting or UDP/IPv4 broadcast - then all listeners on the /64-net or IPv4-subnet would receive the messages being broadcasted.

About Documently

For Documently, we are using RabbitMQ as the message broker/message hub and MassTransit for managing poision messages, health monitoring, RabbitMQ connection management, message serialization, polymorphic message subscriptions/publish and having a library that contains the logic for attaching message meta-data and selecting the exchange and queue names.