Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make future prices editable #220

Open
tomaszpatrzek opened this issue Dec 19, 2022 · 3 comments
Open

make future prices editable #220

tomaszpatrzek opened this issue Dec 19, 2022 · 3 comments
Assignees

Comments

@tomaszpatrzek
Copy link
Collaborator

next step of issue: #190

@bryszard
Copy link
Collaborator

bryszard commented Mar 8, 2023

My idea how to achieve it:

  1. Make Price an independent read model with prices table, which would be associated to the Product. This would substitute the current_prices_calendar attribute. An entry in prices, beside the reference to a product, would have valid_from and value attributes. We could also add a currency and build a value object for Money.
  2. Prices will have their identities, which will allow us to update or delete them.

Alternatively, we would need to edit the whole current_prices_calendar whenever we want to update the prices, because the entries in the calendar have no identities. This solution looks to me like a workaround.

There is also one issue with the current_prices_calendar. I don't see a logic to cut off the past prices. So it does not really contain the current prices, but just all the prices.

@andrzejkrzywda
Copy link
Contributor

Thanks for communicating the ideas!

They made me think about the current design.

I think we can get rid of the pricing calendar.

If we allow adding products to offer with the price, we don't need the prices info anymore.

If price is passed as part of the command things get simpler.

I think it's fair to assume that adding a product to an offer requires a price.

What would be the point of offering a product without a price?

Where can we get the price from?
From the same place where the buyer makes a decision - from the read model of the Public Offer.

So, at the controller level when we initialize the command we grab the price too.

This could fix a bug which we probably have now - if the price changes after the offer was created, the offer price would change too, right?

What do you think?

@bryszard
Copy link
Collaborator

Thank you for you answer, Andrzej.

I don't fully understand what you're proposing.

If we allow adding products to offer with the price, we don't need the prices info anymore.

We already do have the price attribute on the the PublicOffer::Product and we react to the Pricing::PriceSet event.

Where can we get the price from?
From the same place where the buyer makes a decision - from the read model of the Public Offer.

But the read model on the Public Offer is showing the current price, not the future one. In the issue we're talking about making the future price editable.

So, at the controller level when we initialize the command we grab the price too.

Which controller and which command do you mean?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants