**Domain Driven Design Passing Events to separate Bounded Contexts**

---

A user action in MVC should generate an Event which is passed to a remote (same LAN) Event handler.

What I've tested:

1. MVC: fire and forget service call (asynchronous) ->
2. (IIS hosted) WCF which gathers data and populates a message ->
3. Sent via EasyNetQ/RabbitMQ ServiceBus ->
4. The event is consumed by a Subscriber (using a DI container initialized from a WCF service endpoint) which handles the event & it's data.

I did some testing to see how it works if the service is called fairly quickly by looping in the MVC side

```
for (int i = 0; i < 200; i++)
{
        ...
        client.MyServiceMethod(someId, startDate); 
        ...
}

```

The MessageQueue part is quick, based on the timestamps it is sent to the queue and received by the subscriber within the same second. Looping through the WCF service calls is very slow. It takes many seconds to loop through them. I tried switching from wsHttpBinding to netTcpBinding, and playing with the serviceThrottling in WCF.

WCF isn't compulsory, but it seems like a separate event handling project (on the publisher end) would be beneficial and could be physically located elsewhere from the MVC app (load reduction etc.). Is WCF plausible for a situation like this, or should I try using Windows services or some other self-hosted e.g. console app etc, or potentially using a thread in MVC to generate the event data, or are there better scenarios? What are the best practices in this type of Event handling system? Basically it seems like it would be beneficial to have something generating the Event data since it has to be handled somewhere while not slowing down the UI that the end user is using.