Model view controller MVC中的控制器是否被视为DDD的应用程序服务？

我将DDD应用于MVC的M部分，经过一些研究（研究！），我意识到我需要我的控制器与域服务（在模型中）交互。这将使我的控制器成为域服务的消费者，从而成为应用程序服务（在DDD术语中）。这准确吗？控制器和DD定义的应用程序服务之间有区别吗？

控制器在DDD中不被视为服务。控制器在UI层中操作。应用程序服务从数据库获取数据，验证数据，将数据传递给客户端（MVC可以是客户端，但来自winforms应用程序的请求也可以是客户端）等等

---

控制器所做的就是为来自UI的请求提供服务。它不是应用程序域的一部分。

分层体系结构将应用程序分为UI层、应用程序层、域层和基础结构层（Vaugn Vernons实施域驱动设计（位置2901））。控制器属于这个更广泛的设计体系结构的“应用层”，因此将直接与模型中的域服务交互，并被视为应用服务。不仅如此，它显然还将使用可用的实体和聚合。

应用程序层位于域层和表示层之间。控制器是表示层的一部分，它向应用层发送命令或查询，应用服务在应用层使用域模型的服务和对象执行这些命令或查询。因此，控制器不同于应用程序服务，它们可能绑定到实际的通信形式，例如HTTP。您不应该直接从控制器调用域服务，这可能是代码放置错误的迹象

• 域服务：封装了不适合域对象的业务逻辑，并且不是典型的CRUD操作- 这些将属于存储库
• 应用程序服务：由外部使用者用来与您的系统对话（想想Web服务）。如果消费者需要使用积垢 行动，他们会暴露在这里

因此，您的服务可能是应用程序服务，而不是域服务，或者部分应用程序服务，部分域服务。你应该检查并重构你的代码。我想4年后这并不重要，但我对目前正在开发的一个应用程序也有同样的想法。此应用程序可能太小，无法在其上使用DDD，因此将控制器与应用程序服务混淆是过度工程的迹象

何时开始添加更多层是一个有趣的问题。我认为每个应用程序都应该从某种连接到该域模型的应用程序开始。因此，如果应用程序足够简单，则可能不需要添加两个以上的层。但这只是一个想法，我对DDD没有太多经验。

中的控制器一点也没有提到。因此，我认为从DDD POV来看，答案是不确定的。所以我会考虑更实际的问题：“我们需要分开控制器和应用服务”吗？ 优点：

• 将输入处理与用例实现分离

缺点：

• 额外的间接层，使对更简单案例的理解复杂化。（通过在许多层中拉取数据来实现一些琐碎的事情也很烦人，而实际上什么都没有做）

---

所以，若输入处理混淆了用例逻辑，我会选择控制器和应用程序服务的分离。如果两者都足够简单，那么我会选择将用例逻辑保留在controller中，这样您就可以很容易地在代码用例中看到与输入处理分开的情况。

controller通过将请求（或其相关部分）传递到模型来服务视图中的请求。MVC是一种体系结构，肯定可以应用于winforms和web应用程序。对于控制员的位置，我有不同意见。视图无疑是唯一的UI层，MVC的目的是将这个UI层与控制器分开。你的观点很好理解；谢谢你的回复。控制器是请求/命令协调员。在六边形体系结构中，控制器位于应用程序服务/命令处理程序/查询处理程序的正上方。控制器是一个请求转换器，与通信协议（上层）和命令/查询处理程序（来自下层的应用程序服务）耦合。控制器可以被视为应用程序服务外观，因为它们转换并准备命令/查询/消息，以便由较低级别的层（应用程序服务/命令查询处理程序）处理。-1因为控制器与DDD无关。这与放置控制器的位置有关，可以说控制器只是消息/通信协调器，它们以两种方式耦合：ui和应用程序服务。您可以在没有UI（纯命令上下文）的有界上下文中使用控制器。您可以有一个仅用于表示的有界上下文（一个仅用于查询2个或更多有界上下文的复合业务组件）。P.S.控制器与UI的耦合度较低，无论从何处，它们都只需要一组请求参数。如果您查看Evan的DDD第72页，您将看到图4.1显示控制器是UI层的一部分。这是有道理的，因为如果V和C在不同的层中，当层之间只能通过间接和接口连接时，它们之间就会有紧密的耦合。@Louis，我没有读过Vaugn Vernons的书，但我刚刚完成了一个成功的DDD项目。我所能说的是，控制器在一个完全独立的项目中，客户项目。我们的客户机是一个MVC前端，它可能是任何其他客户机。应用程序层是一个完全独立的项目，它自力更生。我