Diskussion:Shopping cart functionality
Michael Althoff remarked: Question/Remark: The project is about the definition of an interface - shopping carts can either be a function of the front end or the inventory system of the tour operator. The interface itself does not provide an own shopping cart. Pls check the use case
Peter Holtermann: This requirement is about the implementation of a shopping cart in the the inventory system of the tour operator. But to make that accessible through the String-Interface, we need to expose some kind of reference, which is called BookingRef in the use case. The other additional field BookingMode is something we need anyway in some way or another.
I do not really care about the wording: We could call the container "Shopping Cart" as well as "Reservation" or "Booking Container".
The important parts are:
- The interface has to contain a reference to a container that can contain more than one product. Products could be single products or packages.
- The Products in the container may have different states.
Example workflow:
Find and add a flight
- Container 1
- Flight FRA-PMI/PMI-FRA (ADDED)
Find and add a hotel
- Container 1
- Flight FRA-PMI/PMI-FRA (ADDED)
- Hotel PMI (ADDED)
Find and add a rental car
- Container 1
- Flight FRA-PMI/PMI-FRA (ADDED)
- Hotel PMI (ADDED)
- Rental car (ADDED)
Everythings fine? Ok, book all the stuff in the container
- Container 1
- Flight FRA-PMI/PMI-FRA (BOOKED)
- Hotel PMI (BOOKED)
- Rental car (BOOKED)
Example container with a package and extra rental car
- Example Container 2:
- Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)
- Rental Car
The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.
Note after experts meeting on 08.02.2017:
- Generally the usage of references to containers and items is considered a good idea.
- Details will be examined more closely when dealing with the BookingContainer element.
