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

Question

问这个问题的原因是我一直想知道如何将所有这些不同的概念拼接在一起。有很多关于 DDD、依赖注入(inject)、CQRS、SOA、MVC 的示例和讨论，但关于如何以灵活的方式将它们组合在一起的示例并不多。

我的目标:

开发无需修改或无需修改即可独立运行的模块

更改或重新设计 UI 应该尽可能简单(即 UI 应该尽可能少做，并且“愚蠢”

使用记录在案的模式和原则

为了更容易提出具体问题，主要架构现在看起来像这样:



该示例显示了如何向员工添加备注。员工管理是一种有界上下文。员工有几个属性，其中一个 ICollection<Note> .

绑定(bind)上下文 在我的理解中，分离代码的逻辑位置。每个 BC 都是一个模块。大多数时候，我发现如果需要，他们每个人都可以保证自己的 UI(即某些模块可能适用于 Windows 手机)。

域保存所有业务逻辑。

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

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

Wcf 或 Web Api 是我的应用程序层，它可能属于基础设施而不是外部。该服务还设置了依赖关系，因此所有 UI 需要做的就是请求信息和发送命令。

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

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

所以，问题是:

实现像这样的分层架构真的涉及这么多映射，还是我错过了什么？

是否推荐(甚至聪明)使用 Wcf 服务来运行这样的主要逻辑(它实际上是我的应用程序服务)

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

这个实现有什么问题吗。有什么需要注意的坠落坑吗？

你有什么好的例子可以推荐看，可以帮助我理解所有这些概念应该如何协同工作。

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

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

根据下面的答案，我开始的方法将基于上面的模型和这样的答案:

我只需要处理映射。利大于弊。

我会将应用程序服务拉回基础设施
将 Wcf 视为“适配器”

我将使用命令对象并发送到应用程序服务。不
用域对象污染我的域。

为了降低复杂性，我尝试在没有事件/命令的情况下进行管理
采购，消息总线等。

另外我只想链接到this blog post by Udi Dahan关于 CQRS，我认为这样的事情可以降低复杂性，除非真的需要它们。

Answer 1

映射和层之间存在权衡。某些映射存在的原因之一是因为适当的抽象不可用或不可行。因此，在层之间显式映射通常比尝试实现推断映射的框架更容易，但我离题了；这取决于对该问题的哲学讨论。

WCF 或 WebAPI 服务应该非常精简。将其视为 hexagonal architecture 中的适配器.它应该将所有内容委托(delegate)给应用程序服务。术语服务的混淆导致混淆。总的来说，WCF 或 WebAPI 的目标是使您的域“适应”特定技术，例如 HTTP。 WCF 可以被认为是实现了 开启主机服务在 DDD 行话中。

您提到了 WebAPI，如果您需要 HTTP，它是一种替代方法。最重要的是，要注意这个适应层的作用。正如您所说，最好让 UI 依赖于 DTO，并且通常依赖于使用 WCF 或 WebAPI 或其他任何东西实现的服务契约(Contract)。这使事情变得简单，并允许您在不影响开放主机服务的消费者的情况下改变域的实现。

您应该始终注意不必要的复杂性。分层是一种权衡，有时可能会矫枉过正。例如，在主要是 CRUD 的应用程序中，没有必要分层这么多。此外，如上所述，不要将 WCF 服务视为应用程序服务。相反，将它们视为传输技术和应用程序服务之间的适配器。反过来，将应用程序服务视为您域的外观，无论您的域是使用 DDD 还是事务脚本方法实现的。

真正帮助我理解的是有关六边形架构的引用文章。通过这种方式，您可以将您的域视为核心并围绕它分层，使您的域适应基础架构和服务。你所拥有的似乎已经遵循了这些原则。所有这一切的一个很好的、深入的资源是 Implementing Domain-Driven Design作者 Vaughn Vernon，特别是关于建筑的章节。