On Page 417 you talk about the threading issue with DomainEvents class. Shouldn't this problem only happen in a multi-processing scenario? For example, I distributed the same Bounded Context to two nodes and both receive a CreateProduct event at the same time? Or I created multiple threads purposefully in a single Bounded Context to increase scalability?

Is this problem if I have only one node and one BC running? I was little confused when I read that events from one thread is handled in the other thread. I think the Operating System always saves the context of a thread and return to the same context later to process.

Hey,

Another good question.

The problem with the static DomainEvents class is that it keeps a static collection of registered event handlers that is shared by all threads. This means that event handlers registered in one thread, may be triggered by events being raised in another thread.

An example is probably the best way to explain this.

Imagine we have a web application using ASP.NET. Every new request is handled by a single thread.:

-> User A makes a request to add a product to his basket. In the application service, an event handler is registered for the ProductAddedToBasket event which the domain model will raise once it has added the product.

-> Before the ProdudctAddedtoBasket event is raise, User B makes a request to add a product to her basket. Her item gets added to the basket and triggers the ProductAddedToBasket event.

This will cause the handler registered by User A to be invoked before his product is added to the basket, because the DomainEvents class will invoke all handlers registered for the ProductAddedToBasket event.

Does that help?

You have described a valid case of concurrency. However, isn't okay to any thread to handle the ProductAddedToBasket event and in the case thread that is run for the user A?

The ProductAddedToBasket can be validated for the presence of products in the thread for the user A and say "Sorry, I can't process this event because I don't see any products that you ask me to work on" and keeps the event in the DomainsEvents collection. The thread for the user B can handle the event because it is in the DomainEvents collection and say "I see all the products that you want me to work on so I'm going to process them." In this time thread for the user A adds the products and come back and process the previous event again that it failed to process again.

You can do that, yes. It's not a bad idea.

You put some logic inside your event handler so that the handler knows when it should be invoked and when it should be ignored. For example, inside your event handler you can check that the product ID of the product added to the basket matches the ID of the product that the event handler was registered for.

I may be wrong, but want to know NServiceBus sagas are to solve problems like this?

Generally sagas are used for long-running stateful workflows - lasting hours, days, or even weeks maybe. I think the example we are talking about here is all happening inside the execution of a single web request, so I haven't seen sagas used for this purpose before.