Consider this simplified example: In an online ticket sale website, tickets have variable prices that change over time.
User searches for tickets. Once he finds a ticket he wants, clicks "Buy" and then a quote is issued. Quotes are persisted and they have they own locator that is sent by email. The quote page opens, showing the breakdown of what he is going to pay, and a button to pay. At this point, the ticket is still available for others. If the user clicks on "Pay now", a payment process starts and a Purchase Order is issued with his details.
When a purchase order is paid, the quote status must be set as "Accepted" and reference the purchase order; the ticket status is set as "Sold".
As per requirements, this must happen in an atomic fashion, meaning that it is not acceptable to have a paid purchase order referencing a non accepted quote, or a non sold ticket at any given time. Essentially, eventual consistency is not allowed.
There are two big aggregates,
PurchaseOrder. The first manages the breakdown calculation, taxes, etc... The second manages payment details for a quote, payment event raising, etc... The problem I have is that right now it seems I have to use a transaction across ticket, quote and purchase order when the last is paid.
How may I model this honoring the "Transactions should not cross aggregate boundaries" rule?