Recently I was going through an article (link at the end) on AWS for DynamoDB NoSQL and got to know that they are suggesting to only have a single table with certain access patterns in your NoSQL database.

But previously in all of my projects I generally followed the Domain model pattern and in that what I did was to first identify the domain entities by finding the nouns (or resources in case of finding endpoints as per REST) in my business problem statement and then I create corresponding domain classes/models/entities with state and corresponding verbs as the behaviors ( I generally prefer fat models and thin services so as to avoid breaking of encapsulation and preserve the DRY principle)

Now according to me, DynamoDB’s article is suggesting like we have to just dump everything into a single table and retrieve it later. Although it makes sense because according to me the major use case of using any NoSQL is its schemaless behavior (if we don’t have any fixed schema then why should not we dump everything into a single table?)

Now my question is, in that case, what kind of domain modeling should I do if I want to use an ORM in my application with a NoSQL as a database?

Should we always go with a single table approach in every other NoSQL like Mongo etc?

I know some people can come and say don’t have any models but just have a single class/entity/model with state/data members as Object (Parent of all classes in Java) type so that any column of your corresponding table in DynamoDB can be easily deserialized into that Object’s class instance by the ORM.

But I want to have a strict type of checking on my deserialization process and also I feel this loose type of deserialization process will make my code very unmaintainable and inextensible in the future.

Moreover, it can also hamper the understanding of business logic for the new developers because whenever I join a new project generally I first go/read through all domain models/entities to understand the business logic of my application. Hence I don’t want to go with this approach.

Some can also say don’t use ORMs just create queries just like we do in Hibernate Query Language etc and retrieve the result as a JSON body and de-serialize it as Map of Object etc and iterate over it in the service layer and perform the business logic there itself. But again I don’t want to do this.

Article’s links

• https://www.trek10.com/blog/dynamodb-single-table-relational-modeling
• https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

PS: Just an FYI this question is more around enterprise applications not distributed/scalable applications (having high TPS/QPS). What I have generally seen if people starts daydreaming about distributed system whenever they hear/read the term NoSQL. So RDBMS like MySQL etc also supports sharding, replication, etc and NoSQL is generally preferred because of its schemaless behavior advantage.