很多MVVM的问题通常是相同的：什么应该是模型，什么应该是ViewModel？我们不能真正责怪开发人员，因为在线参考文档不是很好，特别是MSDN的。对于大多数开发人员来说，简化说明是可以理解的。结果是过于简化的模式，不适合复杂的业务应用程序。
MVVM有许多相互矛盾的实现。多年以来，我将在这篇文章中描述一个有效的实施方案。
问题根源
每个人都同意ViewModel定义：它是View的抽象。这种抽象让GUI更容易测试，我们不需要运行解决方案就可以单独测试ViewModel。它将UI设计与UI行为分离。
但是这个ViewModel抽象应该是什么，真的不清楚。通常，实现是一个ViewModel，我们在其中放置了太多的业务逻辑和一个简单的POCO模型（主要是因为ORM）。
在这种情况下，出现了一个问题：当我在一个ViewModel中只使用一个Model时，我是否需要一个ViewModel？难道我直接绑定模型并通知View是否更新了其中一个属性？
DDD来救援
域模型是来自域驱动设计（DDD）的战术模式，它可以使模型适合MVVM。使用DDD，我们希望避免使用贫血模型，模型可能是MVVM实现的内容。
ViewModel只是View的抽象，它操纵着业务逻辑所在的模型。
例如，ViewModel可以使用User来更改地址：
user.ChangeAdress(new Adress("3 route de tartampion", "6900", "Lyon", "France"));
如果我需要几个模型怎么办？
DDD的另一种战术模式可以帮助我们：领域服务，是我们管理域模型之间交互的地方。如果我们找不到更好的地方来为指定的用例提供业务逻辑，我们就会使用它。我们的ViewModel将操纵操作域模型的领域服务。需要多个模型的典型用例是验证。
例如，ViewModel可以使用购买服务来验证命令：
_buyingService.Validate(/*products to buy*/, /*current user*/)
如果我不了解/关心DDD怎么办？
只需用Model替换DomainModel这个词，用BusinessService替换DomainService。将SRP应用于设计类。
例如在C＃中，Model不应该是INotifyPropertyChanged，它是一个UI关注点。ViewModel负责在属性更改时通知View。
同样的想法，ViewModel不应该嵌入业务逻辑，因为它已经负责UI行为。 简单设计的简单规则
- View有责任向用户显示内容。我们不希望这里有任何行为。
- ViewModel有责任表示View的行为。我们谈论的是UI行为，而不是业务行为。
- 模型有责任封装业务逻辑，而不关心它的显示方式。这是我们放置业务行为的地方。
- 如果涉及多个模型以满足业务需求，则业务服务有责任封装给定用例的业务逻辑。
Github上给出一个简单的例子