event-sourcing

I've read this nice post from Jonathan Oliver about handling out of order events. http://blog.jonathanoliver.com/cqrs-out-of-sequence-messages-and-read-models/ The solution that we use is to dequeue a message and to place it in a “holding table” until all messages with a previous sequence are received. When all previous messages have been received we take all messages out of the holding table and run them in sequence through the appropriate handlers. Once all handlers have been executed successfully, we remove the messages from the holding table and commit the updates to the read models. This

I am wondering how granular should a domain event be? For example I have something simple, like changing the firstName, the secondName and the email address on a profile page. Should I have 3 different domain events or just a single one? By coarse grained domain events when I add a new feature, I have to create a new version of the event, so I have to add a new event type, or store event versions in the event storage. By fine grained domain events I don't have these problems, but I have too many small classes. What do you think, what is the best practice in this case? What's the problem with

Please explain why modifying many aggregates at the same time is a bad idea when doing CQRS, ES and DDD. Is there any situations where it still could be ok? Take for example a command such as PurgeAllCompletedTodos. I want this command to lead to one event that update the state of each completed Todo-aggregate by setting IsActive to false. Why is this not good? One reason I could think of: When updating the domain state it's probably good to limit the transaction to a well defined part of the entire state so that only this part need to be write locked during the update. Doing so would allow

EventSourcing works perfectly when we have particular unique EntityID but when I am trying to get information from eventStore other than particular EntityId i am having tough time. I am using CQRS with EventSourcing. As part of event-sourcing we are storing the events in SQL table as columns(EntityID (uniqueKey),EventType,EventObject(eg. UserAdded)). So while storing EventObject we are just serializing the DotNet object and storing it in SQL, So, All the details related to UserAdded event will be in xml format. My concern is I want to make sure the userName which is present in db Should be

Looking for some suggestions for useful discussion groups, articles, success stories, reference apps, and tooling (.Net) on the subject of event sourcing. I am already familiar with: Fowler's article: http://martinfowler.com/eaaDev/EventSourcing.html Greg Young's Article (with downloaded docs in the comments): http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/ Greg Young's excellent (draft) article on DDDD: http://abdullin.com/storage/uploads/2010/04/2010-04-16_DDDD_Drafts_by_Greg_Young.pdf Anything else I should be reading and looking at? quentin-starin You should look at this

I want to setup a small event sourcing lib. I read a few tutorials online, everything understood so far. The only problem is, in these different tutorials, there are two different database strategies, but without any comments why they use the one they use. So, I want to ask for your opinion. And important, why do you prefer the solution you choose. Solution is the db structure where you create one table for each event. Solution is the db structure where you create only one generic table, and save the events as serialized string to one column. In both cases I'm not sure how they handle event