Hi,
Are their any implicit constraints on the DomainEventStream passed to a call to EventStore.appendEvents?
For example, does the given DES:
only contain events for a single aggregate root id?
guarantee ordering? by seq # within an AR? that events for a given AR are contiguous?
always contain less than N events?
Thanks in advance - looking for ways to optimize persistence through batch writes where possible.
Mike Sample
Hi Mike,
the EventStore implementations dicate the actual constraints. The JpaEventStore can handle a stream containing events of different aggregates, but the FileSystemEventStore can’t. In general, it is best to stick to a stream of only a single Aggregate at a time.
Unfortunately, the API does not tell you howmany events are contained in the stream. Theoretically, it could be infinite. But in practice, it is as big as the number of events that your aggregates apply on a single command.
Which ES implementation do you use? If JPA + Hibernate, you can configure hibernate to do the batching for you. It can buffer insert queries and send them as a single multi-insert query for you.
Cheers,
Allard
Thanks Allard,
If it’s dictated by the EventStore, how does the EventStore communicate those constraints to its callers? If by convention, does that mean the repository or code driving the EventStore is coded to be aware of the various event store implementations?
I am implementing a custom event store that I’d like to plug into the existing code.
Hi Mike,
good questions. The EventSourcingRepository will always provide a sequence of events for the same aggregate id to the event store. So if an event store even supports events for multiple aggregates at once, it will not be used by default. It’s something that should be avoided anyway, but that’s another discussion.
I’ll need to check, but this type of documentation should be on the EventStore interface’s javadoc. If it’s not, I’ve got something to do. 
What kind of event store are you implementing?
Cheers,
Allard