What is Brighter?

Brighter is an implementation of the Command Dispatcher and Command Processor patterns. These allow you to decouple a endpoint, such as an MVC Input Controller from the domain logic that handles the request. The intent is to support the Open-Closed Principle - open to extension, closed for modification - by allowing handlers to be replaced or added, without modifying the calling code; or for the endpoint framework to be replaced without impacting the domain code.

One of the most common uses of Brighter, although not it's only use case is implementing the Command Oriented Interface pattern within a service. We are often used in support of Command Query Responsibility Separation (CQRS).

Brighter also supports sending a request to a handler within another process, using message-oriented middleware (cf Kafka, RabbitMQ, Azure Service Bus, etc.) as a transport to communicate between the two processes. As such it can be used for integration scenarios, such as in a microservices architectural style, or used as a Task Queue to offload work to a queue from a web server, increasing throughput.

 The intent of Brighter is to make the difference between synchronous and asynchronous handling as small as possible: both write the same handlers with the same steps in the sequence. On the producer side, sending asynchronously is just a different method on the dispatcher. On the consumer side a Dispatcher library helps implement the endpoint code so that marshalling to an asynchronous handler is as friction-free a manner as possible.

Bus, Processor or Dispatcher, what's in a name?

.NET projects that support task queues - pushing work onto a queue to be handled asynchronously by one or more consumers - tend to use the term Bus in their naming regardless of whether or not they are implemented using a Bus topology (i.e. publish subscribe, with no central message broker). Brighter tries to avoid this confusion by talking about a Broker architectural style instead