Race between event handlers and read model facade after commands

[t-nelis]

In case anyone's wondering, there are races between event handlers and the read model facade after commands are issued. This is due to the use of ThreadPool.QueueUserWorkItem in FakeBus.Publish.

You can test one for example by creating a new item and freezing one of the threads handling the InventoryItemCreated event (simulating a long database request); the resulting view will not display the item you just created.

Note that this is no eventual consistency matter.

This shouldn't impact the overall architecture which is the point of this project -- just pointing this out so that nobody embarks on a journey looking for magic and finding bugs instead.

[beachwalker]

How to ensure the order of events? seems to be a contract that a Created_Event has to be processed by the handler before any following Changed_Events should be processed. Otherwise there are race conditions, too.