CODEWITHSUNDEEP
user-interfaceviewdomain-driven-designcqrs
Steven
Steven

Reputation: 879

CQRS: One Read Model Per Screen With Complex UI / Multiple Dimensions of Data

I'm struggling to model my queries and read models when it comes to supporting more complicated UIs that support different dimensions of data.

Imagine a scenario where I have an OrderDetailView, for a screen that displays the details of the order (order lines, etc).

Now imagine a screen that displays those same order details, plus a list of delivery companies who can service the order.

Questions:

In a nutshell, from your experience, is it better to accept that two tables are needed for this complicated View, and move ahead? Or recognize that "half" of the view is already provided by an existing view, and have the UI make multiple queries?

Upvotes: 1

Views: 461

Answers (1)

Ankit Vijay
Ankit Vijay

Reputation: 4098

The Model you use in your UI does not necessarily need to be the same as how you store. I would go for creating a separate ViewModel for each screen that you have.

That said depending on the technology you may be able to "reuse" your ViewModel. For example, with ASP.NET there is a concept of Partial View. That is, you can create a common View (and ViewModel) to be reused across multiple screens/ pages.

The Views/Tables on the SQL can be optimized for how they are retrieved. But, that does not stop you from having multiple calls to the DB for a single ViewModel/ screen.

When it comes to the naming of the ViewModel, I suggest naming it according to the operations it performs on UI rather than coupling it with the data-store.

Upvotes: 2

Related Questions