Clarifying MVVM with DDD

I regularly see a lot of questions around MVVM, last one only a few weeks ago.

The problem is usually the same: what should be a Model, and what should be a ViewModel?
We can’t really blame developers, because references online are not really good, especially MSDN’s one. The explanation is simplified to be understandable for most developers. I find the result is an oversimplified pattern which doesn’t fit for complex line of business application.

There are many different and potentially contradictory implementations of MVVM. I’ll describe in this post an effective implementation for me since many years.


Problem roots 

Everybody agree on a ViewModel definition: it is an abstraction of a View. This abstraction is simpler to test than the GUI, we don’t need to run the solution to test a ViewModel in isolation. It decouples UI design from UI behavior.

But what should be in this ViewModel abstraction is really unclear. Usually the implementation is a ViewModel where we put too much business logic, and a simple POCOs Models (mainly because of ORMs). In this case, a question arises: when I use only one Model in one ViewModel, do I need a ViewModel at all ? Can’t I just bind the model and notify the View if one of the properties is updated ?MVVM1

 DDD to the rescue

Domain Model is a tactical pattern from DDD, which could fit the Model in MVVM. Using DDD, we want to avoid Anemic Domain Model, which clarifies what could be a MVVM implementation.

The ViewModel is only an abstraction of the View, and it manipulates Models where the business logic is.

For example a ViewModel can use a User to change an address:

user.ChangeAdress(new Adress("3 route de tartampion", "6900", "Lyon", "France"));

MVVM2What if I need several Models?

Another tactical pattern from DDD could help us: Domain Service. A Domain Service is where we manage interaction between Domain Models. We use it if we do not find a better place to put the business logic for a given use case. Our ViewModel will manipulate Domain Services, which manipulate Domain Models. Typical use case requiring several Models is validation.

For example a ViewModel can use a buying service to validate a command:

_buyingService.Validate(/*products to buy*/, /*current user*/)


What if I don’t know/care about DDD?

Just replace the word DomainModel by Model, and DomainService by BusinessService. Apply SRP to well design classes.

For example in C#, a Model should not be INotifyPropertyChanged, it is a UI concern. It’s the responsibility of a ViewModel to notify a View when a property changed.

In the same idea, a ViewModel should not embed business logic, since it is already responsible for UI behavior. MVVM4Simple rules for simple design 

  • A View has the responsibility to display something to our user. We don’t want any behavior here.
  • A ViewModel has the responsibility to represent the behavior of our View. We talk about UI behavior, not Business behavior.
  • A Model has the responsibility to encapsulate the business logic, and do not care about how it will be display. It’s where we put business behavior.
  • A Business Service has the responsibility to encapsulate the business logic for a given use case, if several Models are involved to meet a business needs.


I tried to give a simple example on Github. (Note that I let the DDD part away).
Any feedback welcome.


Thank you Brian Gibson for the suggestion to add diagrams.




4 thoughts on “Clarifying MVVM with DDD

  1. Hi Ouarzy,

    Interesting article, happy to see that I’m not the only one to think about good correlation between ddd and mvvm.

    However, I think it is dangerous to expose domain models to viewmodels. The more you expose your domain models to external world the more you create coupling.

    I prefer to communicate from viewmodels to bounded contexts through ddd application services or cqrs command/query dispatcher. This keeps
    front-end models decoupled from domain models.
    Furthermore, if you decide later to host your Domain in a microservice, it helps the transition because you already manipulate endpoint to bounded context and not domain models directly.

    This is probably what you mean with usecase services, but it didn’t make sense to me 🙁

    1. Hi Pierre! Thanks for sharing.

      Of course I fully agree, the goal is to help a no DDD practicioner (like in the SO question) to see what they could do easily to keep a clear separation of concern.

      What I mean by usecase services is closer of a DomainService in DDD, but of course what I describe here is not a full MVVM/DDD implementation.

      It is just a MVVM implementation with a clear separation of concern, mainly because I don’t understand why people believe it’s a good idea to have a Model which directly notifies a View.

  2. Hi Ouarzy,

    Thanks your sharing.I have a question. Some time we change the model property and need to notify two views to update it. If we don’t have the model directly notifies , we may do much work to achieve this requirement. Is there any better implementation?

    1. Hi Karl, thanks for the question.

      In this case, instead of one model for two views, you may have one viewModel (or at least the common part) for two views, that’s all.
      If you prefer, your viewModel abstract a view, thus if two views seems to share a lot of common data, they may share a part of a viewModel.

      Now to be fair, even if it seems ok in theory, I never saw a “sharing same viewModel for different view” strategy to be successful on actual projects. It usually creates less readable code.

      Hope it helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

IP Blocking Protection is enabled by IP Address Blocker from