There is a base interface name
ObjectStore. This is just like
Journal in that they have the same motivation. The
ObjectStore is ALWAYS backed by an Actor, just like
Journal and is fully async.
ObjectStore is an abstraction around any sort of object storage, but this is unlike
StateStore that is an
id and a
Object in the
ObjectStore is self defining just like any domain object (entity, aggregate). So think of
ObjectStore as a place where you persist your aggregates but as objects. This could be implemented using Postgres
jsonb and supports searching on JSON properties/fields. FWIW, I have a blog post that is one of my most popular of all times that discusses this thoroughly: https://kalele.io/blog-posts/the-ideal-domain-driven-design-aggregate-store/
The reason this ^^^ is so popular because it addresses challenges that at least 95% of all biz software developers face with ORMs.
Whether you are using JPA, jdbi, Hibernate, Cayenne, jsonb, JDBC, etc., this is an abstraction that can be used to manage it.
I teach literally ~200 people per year from startups to Fortune 10, consult with many, and speak to thousands at conferences. EVERYONE is still using ORM.
Almost everyone I teach is blown away by Event Sourcing and CQRS. This team represents a different class of developers who are already informed and probably using ES and CQRS. That's probably 1% of the software development industry.
Most major corporations will NOT and MAY NEVER buy in to ES, and possibly not CQRS.
We need to provide realistic alternatives. Taking on Reactive and Actors is a huge step on its own.
I am going to demonstrate a simple async transaction support that understands "sessions" that I call, drum roll,
I will leave it here for now. Please wait for the release in the next day. Sorry I am late. Life happens. Thanks so much for your critical feedback and continued support and patience.