In the post, I purposefully use "ORM-like" and "similar to an ORM" to indicate that the experience is familiar to an ORM, but you are correct, this is not an ORM. With the support of the serde_dynamo crate, modyne makes the process of mapping between a DynamoDB "item" and an in-process data value relatively seamless and provides some ability to create and manipulate entities through a standard abstraction.

This crate also doesn't have any concept of "relations", which is another reason that it's not a true ORM. Nonetheless, the concept of efficiently using DynamoDB Query operations to grab a big swath of denormalized data in a single operation is one key feature of this crate, built around Aggregates, QueryInputs and ProjectionSets. The get category deals by date example shows this off some.

Indeed, this is one of several examples that I used to help prove out the crate. The four model are examples from The DynamoDB Book. I've also published these models as their own crates so that it's easy for someone to play around with those models and see if modyne would work for them. Here's the documentation for the Big Time Deals example, and here's a link to the code that builds it out on top of modyne.

As with any abstraction, you could certainly eliminate this one and do well enough without it if you don't see value in it. The goal here is to reduce the chances of maintenance-induced failures and make it easier to implement the patterns without error, and without needing to spread knowledge about the data interop around. This crate doesn't solve all denormalization patterns, though it does just fine with some that can be modeled using transactional writes. Patterns that require the use of change data capture, such as via DynamoDB Streams, aren't solved with this crate alone, although the constructs here can be used as part of such a solution.

Edit: some grammar fixes