4 ms·

Persisting a log of events. Used with CQRS and event-sourcing to decouple the Read model(s) from the Command layer for benefits like: multiple read models (proj

• slowmovintarget 8y ago
  In the parlance of Domain-Driven Design, every aggregate (think object instance as a loose equivalence) is its own stream of events. Loading aggregates involves replaying events until you are caught up. The key design requirement here is to deeply understand the reads your application will need to perform. The downsides are you have to push the data somewhere else to digest and report on it. Relations are tough to model, too, as events that happen to more than one aggregate essentially have to repeat the data in each stream in the form appropriate to that domain entity. (You can often model this as one event causing another. Projections work less well for this circumstance.) This can make it hard to draw data from the underlying store. Instead you must "hydrate" it into objects in memory to ask questions of it, though projections can help. EventStore is definitely not the right choice if you need ad hoc query capability. (I used EventStore in production for 2 years with F#.) I'd classify this as an exotic data store. Use it if you have a really strong need for event-sourcing. Me... I'd likely choose Datomic instead.