How to do domain modelling in NoSQL?

[pulkitent]

Recently I was going through an article (link at the end) on AWS for DynamoDB NoSQL and got to know that they are suggesting only having 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, DyanmoDB's article is suggesting that 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?

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 or HasMap of Object 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 is if people start daydreaming about distributed systems whenever they hear/read the term NoSQL. So RDBMS like MySQL etc also support sharding, replication, etc, and NoSQL is generally preferred because of its schemaless behavior advantage.

[pulkitent]

@valentinacupac would you like to share your thoughts here?

[valentinajemuovic]

Now according to me, DyanmoDB's article is suggesting that we have to just dump everything into a single table and retrieve it later.

Yes, that's fine. In the infrastructure layer, you can do whatever is most suitable for the DB you're integrating with.

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?

Domain model should be relatively independent. If it's dependent on ORM vs NoSQL, then there's no point to the domain model. So with the above, we can have a domain model Customers, Orders, Products. With ORM, that would be 3 tables. With DyanmoDB ok if all one table. But it doesn't change the domain model.

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 or HasMap of Object type so that any column of your corresponding table in DynamoDB can be easily deserialized into that Object's class instance by the ORM.

Yes, that choice is fine - for the infrastructure layer. In the infrastructure layer, you make whatever objects are needed to make serialization/deserialization easy.

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.

Yes, I also prefer strict type checking, do it in the infrastructure.

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.

In the domain layer, it should be just the entities/VOs, etc... no serialization/deserialization.
In the infrastructure layer, that's where serialization/deserialzation is.

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.

The choice of ORM versus writing SQL queries - both are valid choices, but it belongs to infrastructure only, it should not pollute the domain model. Whether one retrieves it as a JSOn and deserializes is again a choice which belongs to infrastructure only.