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

Alternative checkout flow proposal #192

Open
wants to merge 5 commits into
base: master
from
Open
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.

Always

Just for now

@@ -0,0 +1,63 @@
# Alternative checkout flow

In scope of work on GraphQL and storefront APIs we have an opportunity to improve design and features of storefront checkout.

The purpose of this document is to discuss possible alternatives to current Magento checkout flow.

The cart is just a container for the items the user wants to purchase. In the proposed flow the cart is created as soon as user adds product to cart. The data from cart entity should be enough to render minicart and cart pages. Taxes and other adjustments are not calculated at these steps.

The quote, on the other hand, contains a full break down of all adjustments calculated. It provides the user with the total he has to pay for the items in the cart.

It is possible to split cart items into separate quotes. This can be done based on shipping addresses or shipping sources.

Each quote is used to create a separate order. Multiple payment methods (with independent billing address each) can be selected during each order creation.

Cart will depend on Catalog. Quote will depend on Cart and must not depend on Catalog. Order will depend on Quote and must not depend on Cart or Catalog.

This comment has been minimized.

Copy link
@Vinai

Vinai Jun 20, 2019

Quote will depend on Cart and must not depend on Catalog

Why?
I don't see the benefit of this. I see the attraction of it, but I think it's wrong. It's an unnatural restriction. Signs of this are how awkward it is to pass the product dimensions. The same problems will occur also for example when other product data is required for totals calculation by third parties.


1. When Quote is created?
* For physical products on Review & Payments step
* For virtual products billing address has to be entered first
1. Cart properties:
* Line Items:

This comment has been minimized.

Copy link
@Vinai

Vinai Jun 20, 2019

Can more information on how different product types would be represented be added to the proposal?
Currently a product in the quote is represented by one or more quote items. Each quote item can have one or more quote item options to store relevant data.
These options are used for many different things, starting from enabling reorders to linking of related quote items over additional data to display on line items to many different types of customizations.
Because they are so heavily used I would like to read a little on how those problems would be solved with this proposal

* SKU
* Selected options (custom/configurable)
* Quantity
* Regular price
* Price
4. Applicable cart rules calculator arguments

This comment has been minimized.

Copy link
@Vinai

Vinai Jun 20, 2019

What is the benefit of separating out the cart rules from the totals calculation?

* Cart
* Addresses

This comment has been minimized.

Copy link
@akaplya

akaplya Jun 19, 2019

Contributor

we need to pass some kind buyer representation here

This comment has been minimized.

Copy link
@Vinai

Vinai Jun 20, 2019

As a response to a previous comment: the "buyer" that needs to be would be the customer.

* Date & Time (admin preview)
2. Quote factory arguments: Quote

This comment has been minimized.

Copy link
@Vinai

Vinai Jun 20, 2019

The Quote/QuoteFactory still seems like an aggregate for all entities required by checkout to me. If I understand correctly one of the suggestions of this proposal is to not build the quote over time, but all required data has to be provided at creation.
If this data is aggregated over time, where would it be stored? In the API client (e.g. store front)?

* !Line Items
* Dimensions (weight & size) (based on LineItems)
* Shipping (requited for physical products)
* Address
* Selected Shipping Method
* Billing address (required for virtual products). Need use cases
* Coupons
* Gift cards

This comment has been minimized.

Copy link
@akaplya

akaplya Jun 19, 2019

Contributor

Gift cards, coupons and store credits may be moved to the payment step.

* Store credit
* Cart rules (calculated by Applicable catalog rules calculator)
* Customer
2. Totals calculator: Totals

This comment has been minimized.

Copy link
@Vinai

Vinai Jun 20, 2019

in the video of the architecture meeting where this proposal was discussed it was mentioned that totals are entities. Was that meant literally?
From my point of view the totals are a function of the quote.
The results of the calculation may be stored for performance reasons, but a total does not have any identity over time.
Also, I didn't understand the point about how this new proposal allows for sorting of total calculation.
It sounded as if that is not possible in the current implementation. However, it certainly is possible.

The downside of the current implementation is that each total aggregates it's results on the quote items and the quote. Shared mutable state is always tricky. However, it does allow for many customizations where one total calculation can change the value of a previous one. After listening to the discussion, I'm not sure if the total results where supposed to be immutable or not. If they are, how would such customizations be possible?

This comment has been minimized.

Copy link
@joni-jones

joni-jones Jun 20, 2019

Contributor

in the video of the architecture meeting where this proposal was discussed it was mentioned that totals are entities. Was that meant literally?

The idea is to have a separate immutable extensible entity for totals which can be used in other entities like order, invoice, credit memo because there are issues with the calculation of their total.

I didn't understand the point about how this new proposal allows for sorting of total calculation.

There will be some kind of class which will check the configuration and create to a composite of totals in the order according to configuration or applied rules (like cart rules).

It sounded as if that is not possible in the current implementation.

Actually no. The point was that the current mechanism is hard to understand because you can see the only configuration in Admin Panel and logic is smashed across the code. The main idea is making it more visible (even provide some kind of visualization in Admin Panel) and have only one place in the code.

After listening to the discussion, I'm not sure if the total results where supposed to be immutable or not. If they are, how would such customizations be possible?

Totals should be immutable. Each totals calculator uses the result of previous totals calculator, any extension/customization can add own calculator to the list.

* QuoteArgumentDTO
* PreviousTotals
5. Quote
* LineItems
* Totals
* Adjustments
* Taxes
* Cart rule discounts
* Shipping addresses
* Coupons

This comment has been minimized.

Copy link
@AlexMaxHorkun

AlexMaxHorkun Jun 19, 2019

Contributor

Why are coupons, gift card codes, store credit are not part of (price) Adjustments? It would make sense for quotes to accept a list of abstract PriceAdjustmentInterface which would be used when calculating totals and to show users which adjustments were applied to their cart/order/quote. I don't think that quote should explicetly rely on taxes, coupons etc. And there must be a mechanism for 3rd-party developers to add their own adjustments. Having an abstract PriceAdjustmentInterface DTO seems that quotes would receive seems like a step to that direction

* Gift cards
* Store credit
* Customer (optional)
6. Place Order: Order

This comment has been minimized.

Copy link
@akaplya

akaplya Jun 19, 2019

Contributor

we allow creating multiple quotas based on the single cart (quote segregation based on addresses), from my standpoint it makes sense to make order placement as an atomic operation which allows submitting multiple quotes. It runs us in another question - multiple payments handling together. but this also has a sense. Orders with different destination mean addresses may have different process flow which is fine. For example, the multi-tenant installation will require such functionality.

* Quote
* PaymentMethods with Billing Addresses

### Quote creation flow

![Quote Calculation](../img/alternative-quote-calculation.png)
Binary file not shown.
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.