The order capability describes the service landscape enabling Civilians or Charities to redeem their points. The shown services support the architecture decision described in the redeem points ADR.
It should be mentioned that the process of redeeming points is a triangular contract between a user (might be a civilian or charity in that case), the business itself and the Hey, Blue! webshop as shown in the following diagram.
The following list describes main responsibilities of the different services in the Order Capability.
- Provides the catalog of purchasable goods and services
- Provides a shopping cart per user. This cart is persisted to a database to enable a seamless transition between devices.
- Calculates discounted prices with informations from Catalog (offering) and User (available Points) services.
- Verifies the payment authorization with the Payment Gateway service.
- Sends the finalized order to the Order service.
- Provides information about available Points of the logged-in User.
- Anti-Corruption Layer to integrate different modern Payment Providers (e.g. PayPal, Stripe, Apple Pay, ...)
- Acknowledges the Checkout service that a payment is authorized.
- Acknowledges the Order service that a payment is being processed.
- As orders are long-living entities in our domain, they are persisted in a database.
- Instructs Payment Gateway to process a payment.
- Updates catalog accordingly to order.
- Queues paid orders for dispatching.
- Updates order state when an order is dispatched or shipped
- Microkernel Architecture with Plugins for communicating orders with Businesses (see ADR04 Dispatcher Architecture).
- Takes orders from Order services.
- Sends order to Business.
- Receives order confirmation, declines and shipment updates from Business.
- Queues status updates for Order servie.
- Dedicated service to process notifications.
The following sequence diagram shows the control flow from the moment in which the User decides to checkout his cart.
Some calls, e.g. to Notification service, can be asynchronous to decouple the system and handle load spikes gracefully (see ADR02 Event-Driven Design). Especially the communication with the Dispatcher service, where each Plugin may handle orders differently (including different delays and responses), should not block the checkout process. It is common for Users to receive information about shipment hours or even days after checkout.
Operations that require interaction with the User (e.g. authorizing a payment) should be synchronous to block the current process until the result is received.