Schedule price change for the future

[andrzejkrzywda]

I'm not sure, but maybe one possible approach to this would be https://railseventstore.org/docs/v2/bi-temporal/ Bi-temporal Event Sourcing, where we publish a normal PriceSet event, but we set the valid_at metadata.

@mpraglowski sounds good?

[mpraglowski]

Bi-temporal Event Sourcing will be fine when you have situation where "business validity date" is different than event publication date - seems to be a good match here.

[lukaszreszke]

Backend part is now committed in b7c8395
However, there are some concerns about the solution. Please check the commit message.

[andrzejkrzywda]

Thanks for the implementation!

It's much easier to reason about this strategy when we see the code.

I agree with the pros/cons.

What alternatives do we have?

Sending commands to the future?

[lukaszreszke]

I didn't think about this. Scheduling commands for the future sounds like an alternative. But it seems like we'd have to build some infrastructure in order to achieve that. And also, low chance, that the command might be rejected and the price wouldn't be applied. Such a situation would be highly undesired when using some kind of pricing planning strategy. But that's a low chance. Reasons for failure might be different however the outcome would be harmful.

When we were implementing the scheduling feature with @fidel we thought that perhaps we should consider a different model for pricing. Initial idea was that we could have the valid_since date. It eventually evolved and we thought that maybe price could also be available in a certain period of time. When I think about this now, maybe some kind of period. Open-ended. Close-ended. Not sure if those are proper domain names. What do you think about such an approach/direction?

I would also like to highlight the fact that the current solution is acceptable in my opinion. If time to market would be the only factor I think it's a good value for time spent. Also not that hard to change in the future. However, it feels like debt in terms of the domain model. Perhaps we're limiting ourselves, but we don't know yet about the potential use case. Or we don't know the domain enough, yet.

[lukaszreszke]

We had some discussions and this is clarified for me now. If you think about your events as part of the domain, then this solution makes total sense 👍

[lukaszreszke]

Only the backend part is finished. UI is still up for grabs

[tomaszpatrzek]

completed future prices fronted, for now only adding new future prices.
Next steps extracted:

• Remove price column from Product read model #216
• refactor: introduce PricingCatalog::Entry #217
• allow to remove not saved future price entry #218
• update product with no reload #219
• make future prices editable #220