[andrewsw]

We are working with ASP.NET Core MVC. We are also utilising Domain Driven Design and CQRS.

The end-goal is to monitor a process. That is, to record stats such as how far a customer got through a process.

There is an application process that has seven steps. Each step is a different page/view. We have a ViewModel for each step/view, and at each step data is written, and read from, a database (to re/assemble a ViewModel) - this is the monitoring that is sought.

My question is, isn't this over-engineering? My suggesting is to have a single ViewModel for the "process". One argument against this is that at different points a select-list of values is populated, and it would be cumbersome to maintain and store/retrieve these values as part of one ViewModel. To me, this is something we are doing anyway, and I suspect that it is possible to inject and discard properties of a ViewModel. (The lists are only needed for particular steps anyway(?).)

To be a little more specific, the process involves choosing a incident type, where it happened, providing personal details. The drop-down lists are, for example, for a list of streets and a postcode-based address list.

Is a single ViewModel appropriate for a single "process" even though the process occurs across several steps/pages?