CODEWITHSUNDEEP
domain-driven-designnosql
Tom Shane
Tom Shane

Reputation: 704

DDD NoSQL Storage and Domain Model vs. View Model

I'm trying to use DDD pattern and as a persistent storage I'm considering use of a NoSQL database like LiteDB, RavenDB or DocumentDB.

One of the advantages for me, over relational DB, would be my domain models (whole aggregates) could be serialized as a JSON document and stored in a DB avoiding domain model to data model mapping.

But what about reading the data for the purpose of displaying it on the screen. My UI is displaying views based on a view models, but how to construct them? Do I query the document DB via. my domain model and then map it to view model?

I'm asking this, because it's usually mentioned "don't use your domain model for queries (read model)".

Upvotes: 0

Views: 1793

Answers (2)

Alexey Zimarev
Alexey Zimarev

Reputation: 19640

It is important to understand that your domain model consists of both behaviour and state. The only thing you need to persist is state.

When you realise this, you will also figure out that an aggregate state is not something scary to run your queries on. But you definitely should not use your repositories to compose read/view models - simple queries would suffice. There it becomes handy to separate your domain objects state into simple DTOs (documents), which you will store in the database, and keep them as properties in your domain objects. This is a bit different than shown in the book but in practice it works well. You will at least stop worrying if you are encapsulating good enough and will not write serialisation and persistence tests. This article mentions it under the Domain Object Backed By a State Object section.

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57279

One of the advantages for me, over relational DB, would be my domain models (whole aggregates) could be serialized as a JSON document and stored in a DB avoiding domain model to data model mapping.

Yup, that's good.

But what about reading the data for the purpose of displaying it on the screen. My UI is displaying views based on a view models, but how to construct them? Do I query the document DB via. my domain model and then map it to view model?

Yes. The interesting question is when.

You can do that work synchronously with the request.

You can do that work synchronously with the request, but cache the result, so that subsequent queries of the same view are faster.

You can do that work asynchronously -- using background processes to load views into the cache, so that all of the queries are quick.

The basic idea is that each time you write a change to the document, you signal the asynchronous process that a change has happened, and then the process loads the data that it needs to update the cached view.

The "cache" might be, for example, a document store that holds your most recently composed view model.

The cached view might also include meta data that allows to determine at the time of the request if you need to rebuild the view. RFC 7234 is probably a good place to start when thinking about cache meta data.

As Pawel noted, separating the write model and the read model is the big theme of . There's quiet a lot of literature available. I'd suggest starting from Martin Fowler's overview.

Upvotes: 1

Related Questions