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

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

我的目标：

开发只需很少修改或没有修改就可以独立运行的模块

更改或返工UI应尽可能简单（即UI应尽可能少做，并且“愚蠢”）

使用文档化的模式和原则

为了便于提出具体问题，主要结构如下所示：

该示例显示如何向员工添加注释。员工管理是一个有界上下文。员工有多个属性，其中包括

ICollection

绑定上下文在我的理解中是分离代码的逻辑位置。每个BC都是一个模块。大多数情况下，我发现它们中的每一个都可以在需要时保证自己的UI（即，某些模块可能适用于Windows phone）

域包含所有业务逻辑

基础架构包含存储库实现和服务，用于发送邮件、保存不属于该域的文件和实用程序。我正在考虑在多个域中使用一些常见的服务功能（如发送电子邮件）作为一种API，我可以引用它来保存一些代码，这些代码在几个BC中实现相同的东西

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

Wcf或Web Api类似于我的应用程序层，它可能属于基础架构，而不属于外部。此服务还设置依赖项，因此UI需要做的只是请求信息和发送命令

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

在步骤1中，本例中的EmployeeDto只是一些员工属性，用于显示需要记录的员工的用户信息（例如关于新体验的记录或类似内容）

那么，问题是：

实现这样一个分层的arcitecture真的需要这么多映射吗，还是我遗漏了什么

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

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

这个实现有什么问题吗？有什么需要注意的地方吗

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

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

然而，正如下面的一些评论中所提到的，我觉得有些示例倾向于推荐或实施事件和/或命令源、消息总线等。对我来说，现在计划这种级别的扩展是过分的。对于许多业务应用程序来说，这是一个“大问题”（就内部应用程序而言，最多可以考虑几千个）处理大量数据的用户，而不是一个高度协作的领域，因为需要实现通常与CQR关联的事件和命令队列来应对这一问题

基于以下答案，我将开始采用的方法将基于上述模型和以下答案：

我只需要处理地图绘制。这些优点大于缺点

我将把应用程序服务拉回到基础架构和 将WCF作为一个“适配器”

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

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

此外，我只想链接到关于CQR的内容，我认为这样的内容可以降低复杂性，除非它们真的需要

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

WCF或WebAPI服务应该非常精简。将其视为应用程序中的适配器。它应该将所有内容委托给应用程序服务。服务一词的混淆会导致混淆。总体而言，WCF或WebAPI的目标是“适应”您的域与特定技术（如HTTP.WCF）的连接可以被认为是在DDD行话中实现了一个开放主机服务

您提到了WebAPI，如果您想要HTTP，它是一种替代方案。最重要的是，请注意此适配层的作用。正如您所说的，最好让UI依赖于DTO，通常依赖于使用WCF或WebAPI或其他任何工具实现的服务的契约。这使事情变得简单，并允许您改变d的实现omain不会影响开放主机服务的消费者

你应该时刻注意不必要的复杂性。分层是一种折衷，也是一种折衷