In Part II of the book, you talk about different ways to communicate between the Bounded Contexts. As I understand the poller makes the REST API services reactive. On top of that you need an event store. This is a deployment headache because you have to install the services, pollers and the event store too.

1. Do you suggest a poller per BC? Or a single poller that handles any message arriving in the event store?

2. In the poller that you have shown in the book, there is a Thread.Sleep. Are pollers resource hungry? In a long term, is it economical to use a message bus instead of a solution of REST + ES + Pollers? Think about running this system in Azure environment.

3. Do you suggest one Event Store for many Bounded Contexts?

4. Is message ordering a still problem in Event Store (ES) too? You describe this problem in page 224?

1. I would recommend 1 poller for each message that is polled. Each poller is a small component (aka microservice). Our guideline in the book is not to share anything between bounded contexts to avoid technical and team dependencies.

2. We use Thread.sleep to show that the poller has some delay in-between each time it polls. In a production system, you would run the service that is scheduled to run at regular intervals. You could either put the application to sleep in code, but it might be more efficient to shutdown and restart the application every time you want it to run. On Azure you could use the Task Scheduler maybe? http://azure.microsoft.com/en-gb/services/scheduler/

Pollers don't need to be resource hungry. REST and atom can be used to scale as as far as a message bus can.

3. I would recommend that each bounded context has its own event streams. Now, you could have one big event store cluster shared by multiple bounded contexts, or you could have one small ES cluster inside each bounded context. The main constraint is that the bounded contexts do not share data.

This is probably an issue that most developers will discuss with their ops teams - 1 big cluster, or lots of smaller clusters.

4. Messages of the same kind will never be out-of-order because they will be listed on the same atom feed in sequential order. It is possible that messages between bounded contexts may still be out order though.