ES and external services

[Will Comeaux]

How do you handle something like an event sources app that relies on a rules engine?

For example, I have events from a year ago where decisions were made by the rules engine.

However, today, the rules engine changes - in such a way that the events of the past would be 'different'.

How do you handle this? If you have services on which your events depend, do those dependencies have to support event sourcing?

Or is it just the nature of an event-sourced app that "this event happened" and we don't need to "care" how the rules engine was configured in the past?

Thanks,

Will

[Slav Ivanyuk]

Will, I think it'd help if you could provide a concrete sample of such event that needs to be "changed".

 

Slav Ivanyuk

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Will Comeaux]

Not "changed" exactly.

Scenario

January 1 2012 we go live with an OrderProcessing system that is event sourced.

This system utilizes a Corticon Business Rules Engine that is running on some other system - in the ether.

A command RouteOrderToFulfillmentCenter is issued. This command results in the domain calling BusinessRuleEngine.DetermineFulfillmentCenter(orderCriteria).

Say I have three fulfillment centers (A,B,C) and on January 1, 2012, for order X, the rule engine says that fulfillment center B should get the order.

This, in turn causes an event OrderSentToFulfillmentCenter(B)

Now, fastforward to 2013 and some business person makes a change to the rules such that orders that used to go to B now go to A (maybe we closed B and no longer route orders there).

I know we never change events, but what happens if replaying events?

Say, for example, the rules engine is utilized by a read model adapter (something that would get replayed over and over).

How does this work out? Essentially, if I rebuild the read store I need the read model to indicate what the rules engine would have looked like at the time of the event, not at the current status - which would be the case since the business rules engine only knows about "now".

How do we handle these scenarios?

Forgive me, if I ask some novice questions - CQRS and especially ES is very new to me - been in the CRUD world for over 10 years. :)

Thanks!

Will

[Greg Young]

The event is posted as a result of having talked to the rules engine. 

If last year we said gold customers got a 10% discount and we change it this year to 15% we don't go backand send checks to everyone from last year. An event represents a fact that happened at a point in time. It is exceedingly rare to go back and change them (unless you are in a political domain :))

In your example the event says on 4/23/2012 you got an order for x. You routed that order to vendor v. It does not mean that the same order would map to the same vendor today. 

Greg

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

[Ryan Litvak]

I am working through a lot of these type of issues myself.  Feel free to correct me if I am wrong.

 

When you are replaying your events, that is all you are doing.  You are taking what has happened in the past and replaying it in your aggregate to determine what they state is based on those events.  You aren't re-interpreting their meaning by applying today's business rules against them.  Some other process at a past point in time applied a set of business rules to a command and generated an event that routed an order to a fulfillment center.  This happened and there is no going back now.  That information is still relelvant even though an identical command issued today would route to a different fulfillment center.

 

It isn't that you don't care how the rules were configured in the past but you are most interested in the outcome of the past rule configuration than the actual configuration itself.  Your event doesn't depend on the service. The command (handler) does and the outcome of handling that command is an event which your system records.

 

Regards,

 

Ryan