System prevalence in the ddd/cqrs forum

System prevalence has a lot in common with event sourcing and cqrs. I’m not sure about how aware the two communities are of each other so I posted the following to the ddd/cqrs google group. Here’s a link to the post, in case you want to follow the discussion.

Howdy folks, Here’s a short presentation of System Prevalence, a concept you should definitely be familiar with. What if you had enough RAM to hold ALL of your aggregates in memory? According to the prevalent hypothesis you do! A prevalence engine …

  • maintains a single aggregate (the prevalent system) in memory
  • executes queries and command against the aggregate
  • writes commands to the command journal
  • reloads the aggregate by replaying commands from the journal on startup

There are a few very significant things implied here regarding concurrency and transactions:

  • There is no separate database where your “real” data lives, the aggregate in memory IS the data. This means no concurrency/consistency conflicts
  • The entire system is a single aggregate and therefore also a single transactional boundary.
  • In memory is so fast that we can get away with an exclusive lock on the entire system for each command.
  • Full ACID support

As you can see System Prevalence has some similarities with CQRS and Event Sourcing. Generally, there are fewer collaborating types in a prevalent system architecture:

  • Engine
  • Commands
  • Queries
  • the prevalent system (aggregate, remember?)

Notably, there are no command handlers or events. Of the CQRS/ES examples I’ve seen there is a lot of non-transparent complex event plumbing going on in the aggregates. Domain modeling for a prevalent system, on the other hand, is about as transparent as it gets. Prevayler (java), Madeleine (ruby), LiveDb (.NET) are a few of the many system prevalence implementations out there. (I’m the lead dev of LiveDB) Here are some links for additional reading:

© Devrex Labs | Fractal image courtesy of Sven Geier