ORM vs State Store

The classic implementation of the application persistence layer is ORM, all the advantages and disadvantages of which have long been known and have been described many times, for example, by Martin Fowler. In short, the main problem with using ORM is that objects in OOP describe the behavior of some entities, and the ORM tries to work with the data inside these entities. However, the ORM has no information about which part of the class fields is the state of the entity that needs to be saved. To add this information, you have to somehow mark these fields, or describe the specifics of saving and restoring in a separate place in the code. And of course, very often there is a situation of incorrect use of ORM due to a misunderstanding of their specifics and the universal nature of it implementation.

But what could be the alternative to ORM? We can look at the problem from a different angle: if trying to combine an arbitrary object model and a relational representation of data from this model in the database obviously leads to difficulties, we can limit the scope of this tool. However, often such an attempt to simplify the model leads to the fact that all behavior is thrown out of the objects that implement the entities of the domain and only the data structure remains, which leads to the use of an anemic domain model, which is definitely an antipattern.

As I see, the most appropriate solution to these problems as a logical, although not so obvious, explicit separation of the state of domain entities from their behavior and helper fields, which can be done as separate state objects aggregated in entities. When the state of an entity is explicitly defined in this way, saving it (more precisely, saving the entire state tree of the aggregation root and nested entities) is a simple technical task and can be implemented as a separate universal library (or package) with the ability to change the type of storage, be it a SQL database or NoSQL storage or something completely different.

Thus, the implementation of the persistence layer can be some StateStore class which can be a thin wrapper over some kind of ORM, explicitly separating the domain entities state from the business logic.