Declarative vs Imperative domain events

[Erik Ashepa]

Hi,

I work in the trading domain and after a year in development I've made the following observation:

Most of our domain events are very similar to serialized imperative method calls, i.e :

{"event": "OrderFilled", "quantity" : 1, "price": 2, "orderId": "abc" }

which would have a matching applyOrderFilled(orderId, quantity, price) method in the relevant AG. 

Three subsequent order fills would look like:

{"event": "OrderFilled", "quantity" : 1, "price": 2, "orderId": "abc" }

{"event": "OrderFilled", "quantity" : 1, "price": 1, "orderId": "abc" }

{"event": "OrderFilled", "quantity" : 1, "price": 3, "orderId": "abc" }

Which would aggregate to an order with "filledQuantity" : 3.

For the sake of this discussion I could have modelled the same events declaratively as : 

{"event": "OrderFilled", "quantity" : 1, "price": 2, "orderId": "abc" }

{"event": "OrderFilled", "quantity" : 2, "price": 1.5, "orderId": "abc" }

{"event": "OrderFilled", "quantity" : 3, "price": 2, "orderId": "abc" }

Which would also result in the same "filledQuantity" : 3.

We have a use case in which we apply corporate actions such as splits and dividend distribution which trigger more declarative style domain events in our "Trading" bounded context, such as : 

{"event": "OrderAdjusted", "quantity" : 1.5, "price": 4} 

The corporate actions processing is done by a different app in a different bounded context, therefore the "Trading" bounded context really shouldn't care for the mechanics (i.e type of corporate action)

My question is more general : What are the use cases and potential tradeoffs of using a more declarative style of events instead of imperative ones?

Best regards,

Erik.

[Greg Young]

Consider an obvious one credits/debits to an account vs balance updates.

credits/debits are commutative for starters (balance updates are not).
What happens if you get balance updates in the wrong order?

a there are an infinite number of possible calculations I could make
on the credits/debits. If you tell me the balance you are also telling
me the calculation

> --
> 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/d/optout.



--
Studying for the Turing test

[Erik Ashepa]

Hi Greg,

Really good point about persisting the calculation result which could actually change in the future :)

In your example you're obviously favouring the imperative style, am I correct?

But this is an over simplified example, 

Could you please refer to the "PositionAdjusted" example in the "Trading" bounded context I've introduced in my previous post?

I could have modelled it as "PositionQuantityChanged" & "PositionPriceChanged" or some other variation...

Best regards,

Erik.

[Greg Young]

There will always be events like PositionAdjusted ... I am adjusting
to a fixed quantity. There are trade offs.

The reason I favor the first is two-fold. 1) commutative 2) I can
derive the other from the first if I want for integration purposes

[Greg Young]

btw finding an event such as these often times can lead to deeper insight.

As an example.

InventoryCountUpdated count = 27

Following the use case can lead you towards a physical audit where
they hard update the count based on a physical count. Going further
you will learn about concepts like shrinkage and its not just "an
update" http://en.wikipedia.org/wiki/Shrinkage_(accounting)

Greg

[Erik Ashepa]

Hi Greg,

As I mentioned this is was my intuition too...

It gets more interesting when considering Bounded Context though...

Suppose you have a trading BO, there I would definetly keep "AccountCredited" & "AccoutDebited" events.

Buy if I have a ledger Bounded Context (with it's related behaviours, not just a read model),

I would subscribe the the above events and would consider modelling them as two "AccountBalanceIncreased" & "AccountBalanceDecreased" events... 

Or am I missing something?

Best regards,

Erik.

[Greg Young]

You could even decide to publish "balance changed" events in an adapter.

[Erik Ashepa]

Ok, thanks a lot!

I guess bounded context is king in these dilemmas...?

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/70YeoDAV9XI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.