How to deal with Domain Business Logic Changes when using Event Sourcing?

[rebo]

Hi,

New to CQRS, is there a standard pattern to deal with business logic
changes when using Event Sourcing as the "single source of truth".

I can definitely see the advantages of using event sourcing & an event
store to rebuild the domain state. However if the domain logic
changes then the same events may not result in the same domain state
when the events are replayed.

In a traditional Relational DB system, business logic changes can be
freely added to the application under version control and will only
affect the state going forward.

The laborious solution would be to replay events under old business
logic and then switch to new business logic at a point in time when
that is implemented. But this seems unweildy and inelegant to me.

The other solution would be to somehow persist the domain state at a
point in time and then generate a command/event to reload the domain
state using that data. However does this not defeat the purpose of
event sourcing in the first place?

Thanks

-rebo

[Colin Johnsun]

If the business logic changes then you should be raising new events which signify the change in business logic. So basically, the old events will still reflect the old business rules and going forward the new events will reflect the new rules. 

Cheers,

Colin

[rebo]

Ok thanks, thought that may be the case.

So I need to version my business logic as reflected in domain aggregates, then generate an event that effectively switches to the new logic for future events?

I guess its an implementation detail of how to separate the business logic from the state of the domain aggregates so that different business logic versions can be used?

[Greg Young]

there shouldnt be any business logic in the thing handling the event
(only in context of a command can you have behaviours/logic)

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Colin Johnsun]

Yep, I'm new to CQRS too but my understanding is that events should be immutable. 

See this blog post from Jonathan Oliver about immutable events.

http://blog.jonathanoliver.com/2011/03/cqrs-event-sourcing-and-immutable-data/

On Thursday, 17 May 2012, rebo wrote:

[Greg Young]

all events are definitely immutable (its one of the main benefits of
such a system)

[Colin Johnsun]

Thanks for the clarification. I guess it's another thing that helps me understand the differences between events and commands.

[rebo]

Doh, it all becomes clear now.  I thought I had figured out the difference between commands and events but obviously not!

On Thursday, 17 May 2012 12:56:19 UTC+1, Greg Young wrote:

there shouldnt be any business logic in the thing handling the event
(only in context of a command can you have behaviours/logic)