Questions

[justhamade]

@domagojk Thanks for publishing the blog posting and the code, they have been very helpful. I have a bunch of questions about your implementation.

1. Tracking time of events. You have in the event record commitedAt, but then you also add a timestamp to the events before your stringify them. But then again when you retrieve them you add commitedAt to the events . Is there a reason for all of these timestamps that are the same time?
2. I am a bit confused by the linkId for the events vs the streamId for the events vs the linkHash for the view model. It looks like there is a stream of event for each user/link, which makes sense.
3. The event types are very confusing. Is there a reason that they are not separted per domain model? Each domain model will have its own set of domain events. Would it not make sense to keep them organized together? I could see a large application a list of all events in one place get out of control.

I am doing a big refactor of your example and I will post it when it is complete.

[domagojk]

1. timestamp is an optional property of a domain event, commitedAt is an "implemetation detail" used so I can get some kind of ordering in dynamo. They can even be different. For example, you can add events that happened in the past in which case you would use timestamp value to be something meaningful to the domain. commitedAt on the other hand should always represent the time when it was stored in the database. I had a similar use case in one project when I was migrating data from the project's old version.

2. Every time event is saved, I have to provide the streamId. That is just the way I wrote the dynamodb adapter. In this case, streamId is hash created from link url and userId.

3. No reason. It is up to you, really. Since there was only few event types I have defined them together here, but as you predicted, on a bigger project I was working on, I had to separate them and they were indeed easier to work with.