cqrs - Replaying events - validating transitions -

i'm wondering logic should contained when applying event state while replaying events using event sourcing solution.

specifically, i'm wondering validation, i've got entity can in 1 of following status:

• logged
• active
• close
• cancelled

and progress needs logged->active->close or logged->active->cancelled, cannot jump logged close directly example.

now, understand, validation should contained in commands: updatestate check if entity current state allows transition desired one, , produce appropriate event statusupdated persisted event store.

question is, should when replaying back? should update status, or should perform same validation (so if status transition requirements change won't possible load updated entities unless add additional logic), ensure won't end entities not satisfy our current logic?

ps. think i've got problems grasping because in understanding events essentialy 'announcing' happened (and sender state modified) interesting parties can react accordingly. , in case of events loading/replaying, need alter said state instead of 'announce' anything...

you not need perform validation when replaying event stream.

commands model things done in future: ask system you. it's system decide whether or not, e.g. based on business rules , validation.

events in contrast model things have happened. in reality, can not change past.

so, means, when event gets persisted, in consequence of command taken valid at point in time when processed. replaying event stream means have @ happened in past, , can not change this.

hence, not need run validation again.

moreover, means if 1 day business logic changes, things (business accidents!) happened in past still have happened, must not change. hence not allowed use validation logic, may 1 today when when stored events.

and again: can not (and should not) change past :-)

example

supposed have way of validating credit card numbers. customer comes shop, pays, consider / card valid given current set of rules, , fine.

then, 1 day credit card institute changes way credit card numbers calculated, , hence have validation algorithm.

when play past events, payment had happened, or without new validation rules - , can not change fact had happened! if wanted had create new transaction send money customer. again, result in new event, not in changed 1 past.

so, cut long story short: don't validate events against anything. valid definition, as had happened before.