In CQRS, should my read side return DTOs or ViewModels?

Question

I'm having a debate with my coworkers in the design of the read side of a CQRS application.

Option 1: The application read side of my CQRS application returns DTOs, e.g:

public interface IOrderReadService
{
    public OrderDto Load(int id);
}

public class SomeController
{
    public ActionResult SomeAction(int id)
    {
        var dto = ObjectFactory.GetInstance<IOrderReadService>().Load(id);
        var viewModel = Mapper.Map<OrderDto, SomeViewModel>();
        return View(viewModel);
    }
}

public class SomeOtherController
{
    public ActionResult SomeOtherAction(int id)
    {
        var dto = ObjectFactory.GetInstance<IOrderReadService>().Load(id);
        var viewModel = Mapper.Map<OrderDto, SomeOtherViewModel>();
        return View(viewModel);
    }
}

Option 2: The application read side returns ViewModels, e.g.:

public interface IOrderReadService
{
    public SomeViewModel LoadSomething(int id);
    public SomeOtherViewModel LoadSomethingElse(int id);
}

public class SomeController
{
    public ActionResult SomeAction(int id)
    {
        return View(ObjectFactory.GetInstance<IOrderReadService>().LoadSomething(id));
    }
}

public class SomeOtherController
{
    public ActionResult SomeOtherAction(int id)
    {
        return View(ObjectFactory.GetInstance<IOrderReadService>().LoadSomethingElse(id));
    }
}

From the research my coworkers and I have done on the matter, responses appear mixed - it looks like it really depends on context. So I ask you, my dear StackOverflowians:

Does one approach seem to have clear advantages over the other? If so, what are they?

Answer 1

The general advice is one projection per screen (Greg Young) or even one projection per widget (if I understand Udi Dahan correctly).

To consolidate read models into DTOs that once again have to be mapped into separate views contradicts the whole purpose of an optimized read model. It adds complexity and mapping steps that we tried to get rid of in the first place.

My advice: Try to get as close as possible to SELECT * FROM ViewSpecificTable [WHERE ...] or something similar if using NoSQL in your thin read layer.

The concept of Aggregate Roots and their "children" doesn't have too much of an implication on the read side, since these are domain model concepts. You don't want to have a domain model on the read side, it only exists on the write side.

UI platform-specific transformation as mentioned by Mohamed Abed should be done in the UI layer, not in the read model itself.

Long story short: I'd opt for option 2. To not confuse it with a platform-specific ViewModel, I'd rather call it ReadModel but have one per view anyway.

Answer 2

One of the primary principles of DDD/CQRS is that you shouldn't be editing the view model. Instead, task-based screens should guide the user towards issuing explicit commands. If you can't come up with task-based screens, you should be using a different form of CQRS like the one I describe here:

http://udidahan.com/2011/10/02/why-you-should-be-using-cqrs-almost-everywhere/

Answer 3

I would prefer to return DTO to separate the application layer from presentation technology (because each presentation technology may have some requirements on the structure of presentation model) for example a web MVC application binding is different than WPF MVVM binding, also you may require some properties/fields in view models that has nothing to do with application data like for example (SliderWidth, or IsEmailFieldEnabled, ...). Also for example if using WPF MVVM i would need to implement INotifyPropertyChanged interface to allow binding it is not convenient nor related to implement this interface in the application read service.

so i would prefer separating the concern of read data representation from the actual presentation technology and view model.

So option 1 is better for me

Answer 4

A read model is a projection of the write model. It's there to fulfill a specific purpose. In your case that seems providing view models to your MVC controllers. As such, why go thru the trouble of mapping DTO's to Viewmodels? The only reason I could think of was that the benefit of having two separate read models might not outweigh their maintenance cost. But do consider that "merging" read models for the purpose of "reuse" and "lowering maintenance costs" increases complexity for the developer (Can I change this table? Hmmm, I now have two (or more) consumers I have to take into account - smells a bit like database integration all over again).

Just my thoughts.