What are the rules about updating multiple related aggregates?

[Homan Chou]

I have the following domain: 

Our business is to manage merchant's listing quantity across their various sales channels (eBay, Amazon, shopify, etsy, etc).  For example if you are listing 1 pc of T-shirt on multiple channels, and you sell that last piece on eBay, we will then cancel/end your listings on the other channels to reduce the chances of overselling.

We do this as follows:

- For each marketplace, continuously import orders.

- For orders that are unshipped, 'reserve' that ordered quantity, which reduces the inventory 'availability'.

- Compare the new inventory availability with the listing quantity in the other marketplaces.  If there is a difference then update the listings in those marketplaces to the inventory availability.

I think this domain could be very suitable for event sourcing.  It's a complex series of events that lead to other actions, and we need all the help we can get in debugging/explaining what happened when things don't trigger as expected.  I'm having trouble wrapping my head around how to design the commands vs events, what are the bounded contexts and what are the aggregates?

1) Take the most basic action we do: Import new orders continuously.  We make api calls and we get back json/xml.  What is this data in event sourcing land?  Is this a command or is this an event?  The order data we get is a current snapshot of an order coming from a 3rd party system.  We don't get granular events for open, shipped or canceled.  We need to infer whats happening by looking in the json/xml and looking for clues like order_status or quantity_fulfilled or a shipdate timestamp.  

Maybe this incoming data fits a command because it's like saying "process this imported order data".  If it's a new order we then emit an OrderCreated event.  I'm not as clear on other events.  Should I also emit order state changes inferred from the imported data?  Like, OrderCanceled, OrderShipped, OrderPartiallyShipped events?  If the order is already shipped or canceled at the time we imported, then those events don't really take place in our system though.  They feel like made up events.  On the other hand, I should be able to look at an event history to see how I arrive at a current state so it makes sense that we should emit them even if inferred so that we can explicitly see our guesses over time.

2) We want to deduct inventory for the items in the order 

I'm pretty sure Inventory is a different aggregate.  It matches the analogy of an account balance.  It's a quantity for a sku at a warehouse location.  It has to be opened with an initial balance.  When ever new orders are received we deduct the availability.  How do I go from an Order aggregate to the Inventory aggregate?  Is an Order command handler allowed to create events for other aggregates?  Is this a coupling of concerns?  Is this the same bounded context or talking over 2 bounded contexts?  Instead of having the Order command handler fire events for Inventory aggregates, should it just fire it's own OrderCreated event and let some other concern subscribe to that event and fire off Inventory events?

At this point it's starting to feel like a Rube Goldberg machine.  Though the high level concept of event sourcing makes a lot of benefit sense, getting into the details opens a lot of questions.