Let's say I've an event sourced blog engine application in which I can create, publish and un-publish posts... I'm now wondering how to implement the post deletion command. Should I create a post deletion event, store it in the event store, and then, listen to that event to remove the projection, or should I fully delete the post, including any related events from the event store? The problem with the second solution is that I wouldn't be able to rolling back the deletion and I'm pretty sure that removing events from the events store is a really bad practice with event sourced applications.
Thank you for your advise.
If you are in a domain where you are using event sourcing, presumably because there is business value in temporal queries, then you are probably going to want soft deletes, rather than actually destroying the history you have accumulated.
See also: Don't Delete -- Just Don't.
Related
I'm implementing a custom resource controller using the watch API. It needs to create/delete objects in aws when objects are created/deleted in kubernetes.
When it starts up the watch, it receives a list of historic events. However, I noticed that if an object is created and then deleted, these events "cancel out" in the historic event stream. That is, when I start a watch, instead of seeing an ADDED event and a DELETED event for the given object, I see no events at all, as though it never existed. This means that if an object is deleted while the controller is down, it will completely miss this delete event when it starts back up.
For controllers that need to take an action when a kubernetes object is deleted (for example, deleting an object in AWS), what is the recommended approach? Is there a way to make kubernetes keep DELETED events? Is it just expected that controllers work by polling the list of all objects in all namespaces rather than using the watch API?
In case you need to synchronize states or list of existing objects in one system with objects in another system, you should be able to get the lists of objects on both systems, compare them, and deal with the difference.
If you rely only on watching instant events like CREATE and DELETE, you will end up with unsynchronized systems sooner or later.
The only reliable source of information about Kubernetes apiserver events I can imagine is the Audit log.
Usually when talk implementing CQRS it is supposed that commands are sorces for events. But can queries made by user be source of created events in event store? Or such actions (when we need an event that reflects query) should be implemented using command still?
But can queries made by user be source of created events in event store?
Go not to the elves for counsel, for they will answer both no and yes.
So, the "no" part: queries are distinguished by the fact that they don't change the domain model. In a CQRS implementation, the queries are being served by the read model, which may not even have access to your event store at all.
when we need an event that reflects query
The yes part: there's no law that says you can't assemble a history of queries, and stick that in your event store.
But I'm stumped, in that I don't see a clear case where the domain needs an event that reflects a query. That's really weird. My guess would be that needing an event that reflects a query is a hint that your model is broken.
You may be able to make some progress with this by exploring the source of the requirement.
If the requirement is coming from operations, analytics, reporting, usability... then the domain model probably isn't the right place for that information.
If the requirement is coming from your domain experts ("we need to capture these queries so that the model supports the right changes later"), then you should be looking to identify what entity is responsible for tracking that the query happened, and sending an appropriate command to that entity.
According to http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young the component responsible for publishing events using an event publisher is the repository.
My question simply is: Why is that?
In this blog post we are told that:
The domain repository is responsible for publishing the events, this would normally be inside a single transaction together with storing the events in the event store.
I would have expected this as a task of the event store: Once an event (or multiple events) has been stored, it's published.
So why is it on the repository?
Your domain model is unaware of the storing mechanism. On the other hand it must make sure that the appropriate events will be published, no matter if you use an event store, a classical SQL store, or any other means of persistence.
If you rely on the event store to publish the events you'd have a tight coupling to the storage mechanism.
Storing and publishing the event must an atomic instruction because if one of both actions fails, the listeners of this event will be out of sync with the producer of the event.
There is a another (more expensive) solution, compared to publishing the event from the event store, which is to use 2pc transactions (two-phases commit).
you can find some more intereting information here: https://cqrs.wordpress.com/documents/building-event-storage/
I am currently drafting a concept for a (mostly) HTML-based collaboration suite which I plan to implement using CQRS. This software will contain messages that can be sent to the user (which can either be read or unread, obviously) and other elements which shall be marked "new" if they were created after the last user login.
Hardly something new, but I am not quite sure how that would be correctly implemented using CQRS. As I understand it, Change of any kind should, without exception, only be possible via Commands. But creating commands for every single (new) element that is being accessed seems a bit too much, not to mention the overhead.
I don't know if I need it, but what would be the best way to implement a Last-Accessed Timestamp on elements. Basically the same problem like the above, with the difference that the change happens EVERY time the element is accessed, not only the first time for each user.
CQRS seems to be an awesome concept but it really needs more learning material. Can't wait till a book is released :)
Regards
[Edit] No one? Wouldn't have thought that this is such a complicated issue..
I assume you're using event-sourcing in which case once you allow your query-service/event-handlers to raise appropriate events then this becomes fairly easy to solve.
For your messages/elements; when handling the specific creation events of your elements either add to existing or create additional event-handlers, to store to a messages read-model with a status of new and appropriate information about the element.
As part of you're user login I don't see why you can't raise a user-logged-in event (from the security/query service depending on how your implementing authentication) to say the user has logged in. An event-handler could capture this and write the last-login timestamp to a specific user-last-login read-model.
In addition the user-logged-in event-handler would need to update all the new messages (for that user) to an unread status. Seeing as we're changing the status of the messages as the user logs in do you still need to store the last-login timestamp?
For your last-accessed timestamp, perhaps you could just work this into your query service as queries for your different elements complete. Raise a query-completed event with element id/type information.
I'm working on an App that needs to remember events selected by the user from their calendar and I've run into a problem with recurring events.
For non-recurring events I can just store the eventIdentifier and fetch the event from the Event Store when I need it.
But recurring events all share the same eventIdentifier. When I go back to the Event Store to fetch the event (based on the eventIdentifier) I get the very first event in the recurrence chain ... not the Nth recurrence of the event that the user selected.
I can't persist the user selected events by archiving the entire EKEvent object since EventKit doesn't support NSCoding.
I'm considering storing the eventIdentifier and Start & End dates so that I can fetch the correct event from the Event Store ... but that seems pretty kludgy and might make tracking changes the user makes in their calendar between launches of my App tricky.
Any thoughts or suggestions?
The event identifier alone is not enough even for non recurring events. Indeed, it can change when the user moves the event to a different calendar. For recurring events, it may change upon detaching an occurrence or splitting the recurrence.Therefore, it is common practice to search for events using a subset of information (say title, start and due date). You should not rely on event identifiers.
Unfortunately, the framework does not provide us with the raw data of an event, it just provides all of the occurrences of the events in a specified interval. Therefore, there is no such thing (using the framework) as the possibility of retrieving a single recurring event and then expanding its recurrence to get its n-th occurrence: you need to manually post-process the retrieved events in order to find the ones you are interested to.
The problem here is that the APIs provided are not meant for sync purposes. Many developers have complained and still complain about this by filing a bug/feature request using Radar. Until now, Apple answer about is that the APIs fulfill a different purpose, since sync is automatic. However, this is true when syncing through iTunes, but not programmatically.