MVVM，DDD和WPF分层应用程序项目结构指南

我正在尝试在VS中设置我的应用程序的结构，我想“尝试”并在将来对其进行合理的证明。该应用程序将是对旧的Winform应用程序的WPF重写，该应用程序没有遵循任何约定。没有层，层，首字母缩略词等。

这是一个相当大的企业应用程序。我计划将Linq To SQL用作数据库，并且很可能始终是MS SQL。我也有一个现有的技能。

我想尽可能地遵循MVVM和DDD，但是结合使用它们时，我对应用程序的结构感到困惑。让我尝试通过一些示例进行说明。

当我遵循MVVM时，我的文件夹结构可能如下所示：

Views
Models
ViewModels
Helpers

但是这如何适合于简单的DDD分层方法，其中我的项目结构可能类似于此：

MyApp.UI
MyApp.Domain
MyApp.Data

我应该将其Models放在“域”层中还是有3种说法Person？这就引出了另一个问题，即我将数据库对象的存储库和映射放在哪里？我会假设数据...

Views我会进入UI，但ViewModels也会吗？

最后，我将业务逻辑嵌入哪里？

我在CodePlex，DDD示例中发现了以下内容，虽然对您有所帮助，但似乎对Web应用程序有所帮​​助，但这似乎是我的无知。

不要误会我的意思，我知道我可以拥有尽可能多的文件夹，并可以随意命名。我试图弄清楚在哪里放置东西，以便可以扩展，而不是那些地方必须叫什么。

我的问题的核心可能会这样显示。
我有tblPerson产生的物件*.dbml。这很明显，将属于我的“数据”层。
现在，我将拥有Model，DTO，Domain Model或在称为的单独Layer（project？）中调用的任何东西Person。我需要一个Mapper用于Person对tblPerson那个我不知道放在哪里。
然后，我将拥有一个ViewModel，例如，EditPerson它将拥有它自己的属性，Person但可能还会更多。
最后，我将有一个绑定到该ViewModel的View。

需要明确的是，我的假设和猜测已填满该段，我希望有人能为我打气或向他们提供见解，这样从现在开始的6个月到一年内，我不会踢得比自己需要的更多。

MVVM是一种UI模式，在客户端中使用。

客户端中使用的DDD中的域部分可能是模型的一部分

View和ViewModel仅是客户端。

我将存储库放在模型中（或附近），因为它们将模型同步到后端。

是的，很多时候这将导致不同名称空间中的多个Person类。它们可能一开始很相似，但经过几次迭代或发布后可能会变得非常不同。

编辑

阐明有关存储库的部分，并进一步解释有关业务逻辑的位置

如果要创建一个包含单独的客户端和服务器端/后端系统的系统，则可以在客户端和服务器中使用存储库。在客户端中提供服务器的抽象，在服务器中提供其他服务器和数据源的抽象。这只是一个模式。

至于业务规则：如果在客户端中使用这些规则，请确保也在服务器中强制执行这些规则。永远不要信任客户。客户端中的业务规则允许快速进行输入验证，并防止往返服务器。

我确实认为DDD属于服务器端，并且“泄漏”给客户端。

您为WPF应用程序选择MVVM设计模式时有正确的方向。

Do I put the Models in the Domain layer?

是的，您的模型可以放在域中

Where would I put my Repository and mappings of DB Object to Domain Object?

您的存储库可以放置在您的域所在的层中。您的映射对象（也称为DTO-域传输对象）应放置在服务层中，并且可以使用功能强大的映射工具AutoMapper轻松将域对象映射到DTO。

ViewModels also?

您的ViewModels应该放置在客户端（层）上。您可以根据一个或多个DTO构造视图模型。

关于DDD，我建议您阅读有关内容并澄清您确实需要具有域驱动设计模式。此处讨论的是，所有软件应用程序中的95％属于“不太适合使用DDD”类别。

编辑：引用已在上面添加，感谢@Den！

在深入探讨下一步发展之前，让我们谈谈每一层应该做什么。

MVVM的卖点是视图和视图模型之间的绑定。这里的目标是消除视图中的逻辑。
像视图一样，模型应该非常轻巧，并且仅用于访问视图模型运行所必需的信息（数据）。该模型可以混合对不同数据源的访问，但不应具有业务逻辑。在大多数情况下，您需要命中一个数据存储。在某些情况下您不会。如果不这样做，使用模型掩盖来自VM的数据源是适当的。

MVVM的一个隐含点是数据已经存储，您的项目不负责维护其组织。有些项目很幸运能够摆脱这种假设，我从事的大多数项目都不是那么幸运。可以说数据是我们必须应对的另一层。

我将这样布置我的项目：

 project.Views
 project.ViewModel
 project.Model
 project.DataStructs

并且可以根据需要添加此层：

 project.Helpers

我将帮助程序与堆栈的其余部分分开，因此不会混淆您的应用程序堆栈。

免责声明：我不是DDD专家，但我了解一般要旨，并看到了该方法的价值。

您的域将成为您正在考虑的问题集。
该领域模型打算主要对应于您创建的ViewModels; 视图中的一点点；和Model / DataStructs中的一小块。

那么如何解决呢？
如果您有能力更改现有的数据结构，那么您创建的新数据结构应与您要解决的问题相关。有客户对象吗？然后，您应该有一个/一些与客户有关的表。有发票或产品？同一故事-映射到那些业务对象的表和结构应被创建。

域将通过您的ViewModel对象和您提供的这些对象的视图来表示。如果您需要编辑客户记录，那么您将拥有一个用于处理该任务的VM。

关于您的问题：

1. 不要尝试将DDD覆盖到MVVM。只是行不通。DDD不是布局模式，而是一种查看整体问题的方法。
2. 存储库和映射将适当地存在于project.Data或project.Model中。
3. 除非您要调用project.Views，否则没有称为UI的图层。
4. 业务逻辑将进入视图模型。