Skip to content

rollback aggregate to a given revision #154

@stefanomiccoli

Description

@stefanomiccoli

Hi Adriano,

kudos for such a great project.

I honestly can't tell at the moment if my issues are dependant on the lack of knowledge (most likely) of cqrs and event sourcing, my misunderstanding of the docs, or just the wrong use case.

We are using cqrs-domain to store any changes to articles in our platform, pretty much as described in this stackoverflow issue.
So far it helped to keep track of who changed what and when, but we are now about to enrich our webapp by providing the history of changes.

The first step will be to get the list of changes, i.e. all the events generated for a given aggregate id. And here comes the first issue. Looking at the docs and code of cqrs-domain i couldn't find any method to get such list. Merging snippets from this and eventstore projects, the neatest solution I found was to get the eventstore from the domain and then get the events, with something like domain.eventStore.getEvents('streamId', skip, limit, (err, evts) => { /* my business logic */ }). It works just fine, but im not sure that bringing into our code details of eventstore implementation would be ideal. Anywat, is this the correct way to go? any better way im missing?

Then, the big issue... How to restore a prev revision. Before reading that stackoverflow issue, i thought of something very close to the depicted state comparison. Ideally, the way I would achieve this is:

  1. trigger command restoreRevision with the expected streamRevision in payload
  2. load aggregate at the expected revision
  3. compare the aggregate at the target revision with the aggregate at latest revision, make diff and store it as payload of the revisionRestored event
  4. return the aggregate

What I'm missing in step 2 is a method of cqrs-domain to ask for an aggregate at a given point in time (revision). In this case it seems not enough to just load the events with domain.eventStore.getEvents because I would be missing all the logic of the events defined in the domain (i.e. how the event payload has to be merged in the aggregate).

Full of despair, i was looking at the code of the defaultCommandHandler searching for a way how to get all the events and eventually override the commandHandler for a custom one, but then got a hint from the docs that I'm probably looking at the problem from the wrong standpoint

More specifically, this step in the docs sounds a bit obscure. In which way sagas and microservices would overcome the need for a custom command handling?

IMPORTANT HINT:
Is your use case not solvable without a custom command handling? Sagas? Micro-Services?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions