Looking back at this thread, https://groups.google.com/d/topic/event-store/-v09S8iwa4w/discussion, and thinking about how to keep the sequential/numeric IDs my client likes, while using event sourcing. I am left with the same question Michal had at the end. Understanding that streams are great for getting sequential IDs, but how would that work in practice?
Would it be crazy to have a stream for Invoices, where you write all your “Created” events to, and then a projection that creates a new aggregate stream for each InvoiceCreated using the event number from the first write as the Id and linking or copying the created event as the first event in it? Further events on that Aggregate would then write to that stream…
One one hand it feels weird to me, but on the other it kind of aligns with Udi’s whole philosophy of “Don’t create Aggregate Roots” (http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/ - though this is NHibernate-based so not quite the same).
I’m thinking code could be something like
var invoiceId = Invoices.Create(invoiceData); //writes to “invoices” stream, returns event number
// can now return id to client for future requests/ops
At least in that case I am only writing to one stream. But then it feels weird to “generate” the aggregate stream from that event. The only other approach I can think of is to have a dumb stream that is basically just a sequence generator, and write a dumb event to it, get the number back, and use it for the ID in an InvoiceCreated event, which then is saved to the “invoice-id” stream. But now we are doing two writes instead of one. I’m not super-concerned about gaps in numbers should the second write fail, but it just doesn’t seem like a clean approach.
Any thoughts or is anyone doing anything similar with sequential IDs?