Hopefully relevant to the audience - I just posted a blog post on implementing CQRS with event sourcing using EventStore, based on the experience of building out our internal platform: http://blog.softmemes.com/2016/11/12/using-cqrs-with-event-sourcing/
Cheers,
Kristian
I was going to ask your opinion on my earlier post but I see you had already replied there! Clearly you went ahead with using Event Store as an integration layer between services.
May I ask how you handle the security in Event Store? Does each producer or consumer service have its own login to Event Store, or do you use a single, global login?
In terms of the topic of the linked post, how do you handle the notion that certain services “own” certain event streams in Event Store (e.g. the Widget Service is the only actor that should generate events in the Widget streams)? Is it an honor system where services don’t misbehave and post events to streams that they have no business posting to, or do you enforce the separation in some other way?
You could enforce it via ACLs + different logins
For what we do specifically, yes, it is effectively an honor system. Our micro services have full read and write access to even streams, but only the services that own a given category emits to it, much the same as only the service that owns a database table writes to it.
The framework we use make it obvious what types of events that you intend to read or write to in a given service, preventing accidental updates to foreign event categories, but we’ve not found a need yet for enforcing this in EventStore.
Cheers,
Kristian
Greg - yes, but I’d have to set the metadata individually for each stream I create, right? That’s why I suggested that ACL-by-category as a feature in my earlier post.