In DDD/CQRS, should ReadModel act as ViewModel, if not then where belongs responsibility for mapping?

Question

Assume read model ProductCatalogueItem is built from aggregates/write-models, stored separately from write-models, and contains each product available for selling, and has following properties:

• basics: product_code, name, price, number_of_available_stock,
• documentation: short_description, description,...
• product characteristics: weight, length, depth, width, color,...

And, there are two views:

• product list containing list/table/grid of available product offers, and the view needs only following basic properties: product_code, name, price, number_of_available_stock,
• product details showing all the properties - basics, documentation, product characteristics.

Naturally, there come two ViewModels in mind:

• ProductCatalogueListItem containing only basic properties,
• ProductCatalogueItemDetails containing all the properties.

Now,.. there two options (I can see).

---

1. ViewModels are 1:1 representation of ReadModels

Therefore the are two read models, not one, ProductCatalogueListItem and ProductCatalogueItemDetails. And, the read service will have two methods:

• List<ProductCatalogueListItem> searchProducts(FilteringOptions),
• ProductCatalogueItemDetails getProductDetails(product_code).

And, controllers return these models directly (or, mapped to dto for transport layer).

The issue here is filtering,.. should read service perform search query on a different read model, than is returned from the method call? Because, ProductCatalogueListItem doesn't have enough information to perform filtering.

---

2. ViewModels are another project of ReadModels

The read service will have two methods:

• List<ProductCatalogueItem> searchProducts(FilteringOptions),
• ProductCatalogueItem getProduct(product_code).

And, the mapping from ReadModels to ViewModels is done by upper layer (probably controller).

There is no issue with filtering,... But, there is another issue, that more data leave domain layer, than is actually needed. And, controllers would grow with more logic. As there might be different controllers for different transport technologies, then mapping code would probably get duplicated in those controllers.

---

Which approach to organize responsibilities is correct according to DDD/CQRS, or completely something else?

The point is:

• should I build two read models, and search using one, then return other?
• should I build single read model, which is used, and then mapped to limited view to contain only base information for view?

Answer 1

First of all, you do a wrong assertion:

...read model ProductCatalogueItem is built from aggregates/write-models...

Read model doesn't know of aggregates or anything about write model, you build the read model directly from the database, returning the data needed by the UI.

So, the view model is the read model, and it doesn't touch the write model. That's the reason why CQRS exists: for having a different model, the read model, to optimize the queries for returning the data needed by the client.

Update

I will try to explain myself better:

CQRS is simply splitting one object into two, based on the method types. There are two method types: command (any method that mutates state) and query (any method that returns a value). That's all.

When you apply this pattern to the service boundary of an application, you have a write service and a read service, and so you can scale differently the command and query handling, and you can have also two models.

But CQRS is not having two databases, is not messaging, is not eventual consistency, is not updating read model from write model, is not event sourcing. You can do CQRS wihtout them. I say this because I've seen some misconceptions in your assertions.

That said, the design of the read model is done according to what information the user wants to see in the UI, i.e., the read model is the view model, you have no mapping between them, they both are the same model. You can read about it in the references (3) and (6) bellow. I think this answer to your whole question. What I don't understand is the filtering issue.

Some good references

(1) http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

(2) http://www.cqrs.nu/Faq/command-query-responsibility-segregation

(3) "Implementing Domain Driven Design" book, by Vaughn Vernon. Chapter 4: Architecture, "Command-Query Responsibility Segregation, or CQRS" section

(4) https://kalele.io/really-simple-cqrs/

(5) https://martinfowler.com/bliki/CQRS.html

(6) http://udidahan.com/2009/12/09/clarified-cqrs/

Answer 2

As you already built your read model using data which arrived from one or more services, your problem is now in another space(perhaps MVC) rather in CQRS.

Now assume your read model is a db object and ProductCatalogueListItem and ProductCatalogueItemDetails are 2 view models. When you have a request to serve list of products you will make a query in your read db from read model (ProductCatalog table). May be you make queries for additional filters using additional where clauses. Now where do you put your mapping activities in your code after fetching db objects? Its a personal choice. You don't have to do it on uupper llayer aat aall. When I use dapper I fetch db objects using view models inside generic. So I can directly return result from my service method whose return type would be IEnumerable.

For a detail view I would use the same db object. I know CQRS suggests to have different read models for different views. But question yourself - do you really need another db object for detail view? You will need only an id to get all columns where in the first case you needed some selected columns. So I would design your case with a mixture of your 2 above mentioned methods - have 2 service methods returning 2 different objects but instead of having a 1:1 read model to view model have a single read db object and build 2 different view models from it.