Get ProductPrice in command handler from EventStore or MongoDb?

I use EventStore to store events and MongoDb to read. In my CreateOrderCommandHandler I create Order aggregate. In CreateOrderCommandHandler I get ProductId from user without ProductPrice so I need to get ProductPrice from somewhere to fill in my aggregate Order in command handler. Should I get ProductPrice from EventStore (I get events for that product) or from MongoDb (I have collection of products to show users).?

Oh boy … I apologize in advance, this is going to be a rather long answer :slight_smile: There sadly are a lot of “what ifs” and how-should-that-really-works here. If you want the quick answer its …

“it depends”

Now that I have written the required preamble let’s jump right it.

“In my CreateOrderCommandHandler I create Order aggregate. In CreateOrderCommandHandler I get ProductId from user without ProductPrice so I need to get ProductPrice from somewhere to fill in my aggregate Order in command handler. Should I get ProductPrice from EventStore (I get events for that product) or from MongoDb (I have collection of products to show users).?”

So the main question you bring up is whether to get ProductPrice from EventStore or from MongoDb. This is quite an interesting question but leaves out a more interesting question. WHEN do you get the product price from EventStore or mongodb. My guess is the user has just been looking at a screen, likely with the … price on it! in many cases. If not completely clear the main question I believe is what happens when:

I add an item to my basket its $24.99

Some period of time elapses

The price on that item changes

I then checkout

There are a few options here…

I could:

Just use the information I have on pricing and continue…

Try to “relookup” all the pricing information then continue unless a material change occurred in which case I might want to notify the user (usually if it goes down I just come back with “yo buddy the price went lower on this so you got it cheaper!”, they rarely complain about this!

Have rules associated about the “relookup” and price changes which give more flexibility associated to the price change

This last one is where things become more interesting. What if there was a sale, only 2 of this item were sold during the sale and this item coming in is 700 ms after the sale ended? Would this make a difference?

What if in the same situation it occurred but we did a massive number of sales? What if it were 1800 ms? What if …

This same issue occurs with whether or not I have this item. It makes a material difference whether this is a $1 keychain or a $130,000 prefab home kit … no?

In general our write model is assured to be consistent (there are some places where this does not apply but we will assume this to be true for now). Our read model that screens are built off etc is eventually consistent. Our business itself is often eventually consistent in that there is commonly information in the heads of users that they have not yet notified the system of :wink:

There are many trade offs with each decision being made here. What is important is understanding the tradeoffs, there isn’t a right answer here.

Cheers,

Greg

Thx for answer :slight_smile: In my shop there is one rule: if you see in your basket product with price 10$ and product price changes to 50$ during creating order then application should save order with product price = 50$. But one thing is very important - consumer sees product price in his basket from SESSION so it isn’t online price from read database. Now I think I shouldn’t get product price in command handler from read database but pass product price in command to command handler from controller where I get it from read database during creating order because customer can have old price in basket in session. :slight_smile: Because getting product price in command handler from read database is rather ugly?

W dniu wtorek, 25 czerwca 2019 19:43:47 UTC+2 użytkownik Greg Young napisał: