Hi everyone, I have read the online documentation, but I wonder if I have missed something? If this is all explained somewhere I would be grateful for a link, and sorry for bothering you, but:
An aggregate defines a theoretical boundary - so you can bundle domain objects and they can be worked on as a single unit.
You should not reference the child domain objects directly - you should communicate with the root object and it would delegate work within itself.
Domain objects appearing within the aggregate are modeled according to the requirement the aggregate is being created for. Domain objects representing the same thing might appear in different aggregates and look different because they suite a different purpose.
Aggregates are transactional boundaries.
Only a single aggregate should be affected in a single command handler - needing to break this rule hints at a possible refactoring / re-modelling requirement.
An aggregate is created to enforce business invariant’s and is modeled with the parts of the system it needs to perform it’s job. If your system only has a single business invariant or performs only a single task then you would likely only want a single aggregate (and maybe consider using a less heavy architecture!) but in reality you will be modeling many business invariant’s, accounting for many concepts within the business and therefor many aggregates and streams.
Having a single stream would be equivalent to modeling an entire relational database in a single table… IMO - you could do it - but then you could do a lot of things…
w
Wayne,
thanks for the clarification. I think you are describing the DDD concept of ‘aggregate’ http://martinfowler.com/bliki/DDD_Aggregate.html ?
I am looking for a way to represent the CEP concept of ‘aggregate events’ or ‘complex events’ which I do not think fits this definition of ‘aggregate’, so I will refer to ‘complex events’ from now on. A complex event in this sense is the “aggregation of sets or groups of lower-level events into a single higher-level event that expresses the meaning of the lower-level events taken together” (from The Power of Events by David Luckham).
I don’t think this can be modelled by a DDD ‘aggregate’ because one would not want the access the child events only through the complex event. E.g. a single low-level or ‘atomic’ event could be part of several complex events. I am interested in cases in which there could be several higher levels of complex event, so the relationship between events is in general a DAG (Directed Acyclic Graph). Does EventStore have a way to represent such a relationship?
I am still really confused about how your ‘aggregate’ or ‘stream’ works. What is the relationship between events and streams? many-to-one? many-to-many? Does the aggregate/stream do the job of recognising patterns? E.g. recognising when a number of atomic events on a web shop amount to a completed transaction? Does it then generate an event representing the entire transaction? If not, how would you recognise patterns? Would you ever use EventStore with a rules engine such as Drools?
Sorry to ask so many questions. I find the idea of ‘event sourcing’ very interesting and powerful but I am struggling to see how it fits with related ideas such as CEP.
Gareth
Daniel, posts crossed 
“I am looking for a way to represent the CEP concept of ‘aggregate events’ or ‘complex events’ which I do not think fits this definition of ‘aggregate’, so I will refer to ‘complex events’ from now on. A complex event in this sense is the “aggregation of sets or groups of lower-level events into a single higher-level event that expresses the meaning of the lower-level events taken together” (from The Power of Events by David Luckham).” - This sounds like a projection to me : See projections series here http://docs.geteventstore.com/
“I am still really confused about how your ‘aggregate’ or ‘stream’ works. What is the relationship between events and streams? many-to-one? many-to-many?” - You would normally tend to have a stream per aggregate. So, for example, you could have a stream named Order26 which contains all the events that have occurred the relate to an instance of an order. In order to understand fully what an aggregate is, you might want to read Eric Evans Domain Driven Design book.
“Does the aggregate/stream do the job of recognising patterns? E.g. recognising when a number of atomic events on a web shop amount to a completed transaction?” - A stream just contains a sequence of events (nothing more nothing less). But from this sequence, it is possible to rebuild the state of an object such as an order. Using this technique, is generally an alternative to persisting an objects state (i.e. an order) in a relational database.
So, a typical scenario for event sourcing would be: implement a domain model in code that represents the business behavior; save events that change the state of the domain model rather than persist the state using say an ORM; from these events you can rebuild the state in your domain model; because the events contain everything that has ever occurred that affect the state of your domain, you can use these events for alternative purposes like building reporting database, performing analytics, etc.
If you take a look at one of Greg Youngs event sourcing videos, I am sure he will explain this all much clearer than I have 
Daniel,
thanks for your comments which were most helpful, and sorry about the late reply, I have been reading the kindle edition of “Exploring CQRS and Event Sourcing”. Based on this book and its example of a conference booking system I think I am getting a clearer idea of what all these terms means. Let me try to summarise:
Aggregate: in Event Sourcing, this is something that can be constructed (i.e. its state can be recreated) from a stream of events.
An aggregate owns the events needed to recreate it
An aggregate can raise events, including its own events
An event, when raised, must be both persisted and published
The relationship between events and aggregates is many-to-one.
This last point troubles me. In “Exploring…” an Event is persisted with an aggregate ID, and presumably only that aggregate can/should read it. But what if one event contributes to more than one aggregate? Eg what if there is a conference centre that can be booked for several conferences at the same time. Each conference has a SeatsAvailability aggregate that owns its reservations events. But the conference centre cafe would also like to know about reservation events for each day, so it can estimate how many staff to bring in and how many cakes to order. Does the cafe have to query each SeatsAvailability aggregate and add up the results? That seems wrong. The cafe is a different customer and has no business knowing how many attendees registered for each conference. It just wants to know the total. It seems to me there should be perhaps a DailyAttendees aggregate that can subscribe to all reservation events. Or maybe it would be a Projection. But there are surely cases where an Aggregate would be needed.
In general, it seems to me the relationship between Events and Aggregates should be many-to-many and the idea of aggregates owning events seems wrong. Is that a quirk of the “Exploring…” example or a general practice in Event Sourcing? If so, am I missing something?
Thanks again
Gareth
You need to remember that in cqrs you are separating the read side from the write. In the cafe example, the cafe needs to query data from a selection of aggregates. This is generally done using read models/projections.
Here is an link to an article that uses conference booking as an example:
Fwiw, the cafe’s can listen to the conference events in order to build their own models…which might include aggregates/events/projections. From your description, the cafe is a different context.