DDD/CQRS/NSB with RavenDB as only data store

[asiemer]

Great morning all!

I have a customer that is doing a pretty elegant implementation of all things NSB/CQRS/DDD but are 100% on top of RavenDB for data storage purposes.  They are sending messages through MSMQ/DTC.  Saga state in Raven.  But also all of their model persistence is in Raven.

This is a high volume system in terms of transactions but best I can tell (at this point) fairly low on the data footprint side (20tb give or take).  Currently using esent but looking at a migration towards voron.

Wanted to start a conversation with others that have had success with a configuration of this nature...or failures.

Thank you,

Andy

[João Bragança]

Voron doesn't support DTC.

I've used RavenDb as a persistence engine for NEventStore before, but realize now that was a mistake. You are going to have an issue when your repository reads a stream to fill your aggregate - the same problem you'll have with pretty much any document database. You either have to a) keep all events per stream in a single document, which will fall over once your aggregates get large enough or b) use an eventually consistent index (not a good idea when you are supposed to be fully consistent on the write side). Also I believe that with a) it will be a major PITA to figure out which events need to get dispatched to projections.

OTOH We're using RavenDb now for the projection side and are basically happy with it.

CQRS allows us to use more than one database so that we choose the best one for each problem at hand. Why not embrace this?

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Andrew Siemer]

In this case I just walked into this project.  Assessing the current state and their future state based on current implementations.

They aren't doing event sourcing for the most part.  And where they are doing it...it isn't in a manner that you would jump at calling ES per se.

Trying to identify if their current implementation is on the right path. I need to dig more into their use of Raven...why I was curious about others here using it as the sole data store (at scale).

[Thomas Schanko]

I did ES with RavenDb (Esent) on a project with reasonable throughput. If you choose the right strategy for your document ids, you can perfectly store each event in it's own document without getting into trouble with eventual consistency. Loading documents by IdStartsWith (method name maybe different) does not rely on an index.
However, you named the main problem. As Voron does not support distributed transactions, all messaging related code needs to be reviewed.