如何使用DDD和SRP实现可维护和松散耦合的应用程序？

Question

问这个问题的原因是我一直在想如何将所有这些不同的概念缝合在一起。关于DDD、依赖注入、CQRS、SOA、MVC等方面有很多例子和讨论，但关于如何灵活地将它们组合在一起的例子不多。

我的目标：

1. 开发很少或没有修改就能独立运行的模块。
2. 更改或重新工作UI应该尽可能容易(即UI应该尽可能少做，并且是“愚蠢的”。)
3. 使用文档化的模式和原则

为了更容易地提出一个具体的问题，主要的北极建筑现在看起来如下：

​

​

此示例演示如何向员工添加便条。员工管理是一个有界的上下文。雇员有几个属性，其中包括一个ICollection<Note>。

绑定上下文是我所理解的分离代码的逻辑位置。每个BC都是一个模块。在大多数情况下，我发现如果需要，每个模块都可以保证自己的UI (例如，某些模块可以用于Windows )。

域保存所有业务逻辑。

基础设施保存存储库实现，以及用于发送邮件、保存不属于域中的文件和实用程序的服务。我正在考虑在几个领域(如发送电子邮件)中使用的一些公共服务功能，作为一种API，我可以参考它来保存一些代码，在BC的几个领域实现相同的功能。

查询层保存除存储库中获取对象所需的GetById之外的所有查询。查询层可以查询其他持久性实例，并且可能需要为每个UI更改一些实例。

Wcf或Web是我的应用层，它可能属于基础设施，而不是外部。这个服务还设置了依赖项，所以UI所需要做的就是询问信息和发送命令。

这个过程从蓝色箭头开始。阅读模型，因为它包含了大部分信息。

在第1步中，本例中的EmployeeDto只是一些雇员属性，用于显示他们需要记录的员工的用户信息(比如关于新体验的说明或类似的内容)。

所以，问题是：：

1. 像这样的分层结构的实现是否真的涉及到这么多的映射，还是我遗漏了什么？
2. 是否建议(甚至是智能)使用Wcf服务来运行这样的主逻辑(实际上是我的应用程序服务)
3. 在UI层中没有域对象的情况下，是否有Wcf的替代方案？
4. 这个实现有什么问题吗。有什么值得注意的陷井吗？
5. 你有什么好的例子推荐给我看，可以帮助我理解所有这些概念是如何一起工作的。

更新：我现在已经阅读了大部分的文章(相当多的阅读)，除了付费的书(需要更多的时间来做)。所有这些都是非常好的指针，Wcf作为适配器的思维方式似乎是对问题2的一个很好的回答。如果我打算走这条路的话，JGauffins在他的框架上的工作也很有趣。

然而，正如在下面的一些评论中提到的，我觉得有些例子倾向于推荐或实现事件和/或命令源、消息总线等等。对我来说，现在计划这样的规模是太过分了。由于许多业务应用程序--这是一个“大”(就内部应用程序而言，考虑到最多几千个用户)--大量处理大量数据的用户，而不是需要实现事件和命令队列的高度协作域--通常使用CQRS来处理这个问题。

基于下面的答案，我将开始的方法将基于上面的模型，答案如下：

1. 我只需要处理映射问题。利大于弊。
2. 我将把应用程序服务拉回基础设施，并将Wcf视为“适配器”。
3. 我将使用命令对象并发送到应用程序服务。不会用域对象污染我的域。
4. 为了降低复杂性，我现在尝试在没有事件/命令来源、消息总线等情况下进行管理。

此外，我只是想链接到这篇博文由Udi Dahan撰写关于CQRS，我认为这样的事情可以降低复杂性，除非它们是真正需要的。

Answer 1

1. 在映射和层之间有一种权衡。某些映射存在的原因之一是因为适当的抽象是不可用或不可行的。因此，仅仅在层间显式映射比尝试实现一个推断映射的框架要容易得多，但我偏离了；这取决于对这个问题的哲学讨论。
2. WCF或WebAPI服务应该非常薄。把它看作是六角形建筑中的适配器。它应该将一切委托给应用程序服务。服务一词被混为一谈，造成混乱。总的来说，WCF或WebAPI的目标是“调整”您的域以适应特定的技术，如HTTP。WCF可以被认为是用DDD术语实现开放主机服务。
3. 您提到了WebAPI，如果您想要HTTP，这是另一种选择。最重要的是，要意识到这个适配层的作用。正如您所述，最好让UI依赖于DTO，通常是使用WCF或WebAPI或其他任何东西实现的服务契约。这使事情变得简单，并允许您在不影响开放主机服务使用者的情况下改变域的实现。
4. 你应该时刻留意不必要的复杂性。分层是一种权衡，有时它会造成过度的后果。例如，在一个主要是CRUD的应用程序中，没有必要进行如此多的分层。此外，如上所述，不要将WCF服务视为应用程序服务。相反，将它们看作是传输技术和应用程序服务之间的适配器。反过来，将应用程序服务视为域上的外观，而不管您的域是用DDD实现的还是使用事务脚本方法实现的。
5. 真正帮助我理解的是关于六角形建筑的参考文章。这样，您可以将您的域视为处于核心位置，并将其周围的事物分层，使您的域适应基础设施和服务。你所拥有的似乎已经遵循了这些原则。沃恩·弗农( Vernon )的实现领域驱动设计是所有这一切的一个很好的深度资源，特别是关于体系结构的章节。

Answer 2

实现这样的分层体系结构是否真的涉及到如此多的映射，还是我遗漏了什么？

是。问题是它不是同一个物体。它是同一对象的不同表示，但对每个用例都是专门化的。视图模型包含更新GUI的逻辑，DTO是专门用于传输的(可能会标准化以方便传输)。等等，他们看起来可能是一样的，但他们真的不是。

当然，您可以尝试将所有的适应都放到一个类中，但是当应用程序增长时，使用它并不是很有趣。

是否建议(甚至是智能)使用Wcf服务来运行这样的主逻辑(实际上是我的应用程序服务)

你需要某种网络层。我不会让所有客户端应用程序都访问我的数据库。如果您处理数据库模式(如果一些客户端仍然运行旧版本)，则会造成维护噩梦。

通过使用服务器，维护版本差异要容易得多。

请注意，WCF服务定义一旦被使用，就应该被视为常量。任何更改都应该在新接口中定义(例如，MyService2)。

在UI层中没有域对象的情况下，是否有Wcf的替代方案？

你可以看看我的框架。起始帖子：http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/

这个实现有什么问题吗。

我看不出来。看上去你已经很好地掌握了这些概念，以及应该如何使用它们。

有什么值得注意的陷井吗？

不要对查询和命令懒洋洋的。不要让它们变得更加通用，以适应几个用例。当应用程序增长时，它会回来咬你。较小的类更容易维护。

你有什么好的例子推荐给我看，可以帮助我理解所有这些概念是如何一起工作的。

我的链接博客文章和所有其他文章在该系列。