Chapter 12 has an example developed with NSB. To have multiple BCs to communicate to each other, shouldn't all of those BCs share the same Bus and all BCs should send and receive messages from the same Bus, to be specific the same instance of the Bus.

Answering this question will come down to semantics but I'll try my best to be clear. Please let me know if I'm not explaining well though.

Firstly, if you are using NSB to publish external events, each bounded context is a separate software application/component/service deployed independently. Therefore, they cannot share the same instance of Bus class because they are running in different processes, probably on different servers.

What they will share is the same NServiceBus system. An NServiceBus system is a collection of NServiceBus agents - each running inside a separate process, usually on different servers - that communicate with each other over the network.

This arrangement is shown in figure 12-1 on page 183.

Does that make sense?

I think that picture make sense.

I was thinking more in the line of a bunch of Assembly DLLs (BCs) trying to access a common Bus, so the bus instance should be singleton and the same instance. I think I was wrong. I should have thought in the line of ESB as a shared resource like a file or a data base which many BCs trying to access.

Could you please give some insight into how can we do this with Azure Service Bus?

Let me explain my approach. I have five Bounded Contexts. These Bounded Contexts have two components within it. So ,there are totally 10 Assemly Dlls. Each of these components when started in different worker roles in Azure, access the same Enterprise Bus created in Azure. These components make a pub-sub connection with the ASB. For example, a component A sends a OrderCreated message to the Azure Service Bus. This event has been subscribed by component B which lives in a different BC.

Appreciate your insight into this.

Ok, so basically you want to use the bus to publish events over the network to each of your components that are independently deployed as azure worker roles?

In theory, the pattern should be similar to NServiceBus, you'll have some Bus interface where you publish messages, and in the receiver you'll have some type of handler that subscribes to the events it wants to handle.

In practice, Azure Service Bus will have slight differences to NSB. I'll have a look at the Azure Service Bus documentation and sample code and see if I can find something relevant.

Yes. I think the best way to host the Bounded Contexts components in Azure is via Worker roles only. I'm thinking in the line of a deployment strategy which needs only less maintenance. They can be hosted in managed VMs but that is a lot of headache.

The NSB is good and simple. I believe it dominated in a time where we did not have good cloud solutions for scalability and fault tolerence. MS has come up with Service Fabric Reliable Service and Actors recently. In my opinion they have less maintenance headaches.

What I meant by less maintenance headache is that the developers should spend more time in solving business problems rather than doing deployments and app maintenance. How many times we have been to places where building the applications and running them take more time than spending time on figuring out a checkout failure and finding a solution?

I have experienced similar where there are high infrastructural costs of deploying and maintaining applications. This has often been more of a problem on .NET and Windows where it has lacked tooling like chef, puppet, docker, mesos, heroku etc that Linux has been able to rely on heavily for infrastructure automation.

But Microsoft are catching up nowadays with Azure, their container platform, and even their Linux support. I haven't used Azure worker roles but they look like highly-relevant for background jobs and take a way a lot of the menial infrastructure work.