Home/ Questions/Q 6954127
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T14:33:57+00:00

I am currently drafting a concept for a (mostly) HTML-based collaboration suite which I

  • 0

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..

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0