About idempotency

Am I right in assuming that the actual payload is not evaluated? Merely the event ids? If so, I could potentialy slip in different events with the same event id upon each call (until one of them succeeds obviously)? I’m okay with this, in fact I’d prefer it this way.

The reason I’m saying this is that sometimes the event data is not deterministic (e.g. if we were to embed current date time in the payload) if we were to replay a command. In general I consider this a bad idea (the indeterminism) but for current date time I’m inclined to make an exception. Obviously, the better thing to do is provide the datetime from the outside in a deterministic manner. Another example might be copying some data from another aggregate. By the time we replay the command that data might have changed (not perceived as a bad thing by business at that point in time - they just want to snapshot something as part of the event (not necessarily as part of the command)), hence causing the event data to be different. Now again, we could have lengthy discussions about the various trade-offs of making this more deterministic (not having the domain depend too much on the environment so to speak), but the fact remains that for all intended purposes this kind of behavior could happen.

Obviously, for this to work I’d have to remove the datetimes or non-deterministic parts from my MD5 hashing. Fine by me.

Probably smells like a can of worms, right :slight_smile:

Yes, actual data or metadata is never checked, only EventIDs. In your case datetime probably should go into metadata of event?

You are correct the check is on ids

Found this interesting technique that is RFC4122 compliant for deterministic guids (based on content) without colliding with other guid algos.

http://alexandrebrisebois.wordpress.com/2013/11/14/create-predictable-guids-for-your-windows-azure-table-storage-entities/