Need some help understanding an aggregate, what produces it?

[Homan Chou]

I'm a rails developer that recently found ES + CQRS via some high level talks on youtube.  I'm sold on the potential benefits, but stuck on details.

The event itself, for example, looks like it needs an aggregate ID.  So events always happen to aggregates.  But what is producing this aggregate creation event?  How do I know if the aggregate exists or not?

Let's say I have a cron job that is periodically importing orders from a 3rd party system like eBay.  I don't want to duplicate orders, I want to upsert them.

In event sourcing I probably want a domain event like OrderCreated or OrderShipped.  If the order isn't in the system I want OrderCreated, but if the order exists, I want to generate some other change like OrderCanceled or OrderShipped etc.  

Greg mentioned in one talk that the only thing we would ever query the event store by is the aggregate ID.  But if I don't have the aggregate ID, how do I look it up?  Would I look at projections from the command handler?

[Danil Suits]

Warning: novice typing ahead
 

 But if I don't have the aggregate ID, how do I look it up?

One way is to compute it.  Which is to say, if your third party order feed has a unique identifier, then you can create an id for your aggregate that matches it.  For instance, you could use a "named uuid" to compute the id for your aggregate.  You pack the pre-computed id into the command that you send to the command handler; it will read the id from the command, and load the aggregate with that ID from the repository.  The repository will know if this is a new instance of the aggregate or not.

[Antony Koch]

It's worth adding that ES is one way of hydrating your domain.The benefit is the events can be consumed by reliant systems. Couple this with the fact that more events can be raised, of a targeted nature, and real power is provided. To implement CQRS, we would say that commands enter our core business logic, are validated, and then raise an event. Commands will most likely take an ID of some kind, however your application service / command handler layer may perform some look up from an external ID to an internal aggregate ID if needed. It's this ID that propagates out in the events. More likely, though, is that it's important to remember that your command is your contract - if you require the aggregate ID, then it is down to the client constructing the command to retrieve it. This can be done from a read model, or external lookup, or by computing one, as Danil mentioned.