MVC中的Controller是否被认为是DDD的应用服务？

Question

我正在为我的MVC的M部分应用DDD，并经过一些研究（研究！），我已经意识到我需要我的控制器与域服务（在模型中）进行交互。这将使我的控制器成为域服务的使用者，因此也是应用程序服务（以DDD术语）。这准确吗？控制器和DD定义为应用程序服务之间是否存在差异？

Answer 1

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

所有控制器正在处理来自UI的请求。它不属于应用领域。

Answer 2

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

Domain Driven Design: Domain Service, Application Service

  

  
• 域服务：封装不自然适合域对象的业务逻辑，并且不是典型的CRUD操作 -   那些将属于一个存储库。
  
• 应用程序服务：由外部使用者用于与您的系统通信（想想Web服务）。如果消费者需要访问CRUD   操作，他们将暴露在这里。
  

因此，您的服务可能是应用程序服务，而不是域服务，或某些应用程序服务，某些部分域服务。您应该检查并重构您的代码。我想4年后这无关紧要，但我正在开发的应用程序中有同样的想法。此应用程序可能太小而无法在其上使用DDD，因此控制器与应用程序服务混淆是这里过度工程的标志。

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

Answer 3

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

Answer 4

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

优点：

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

缺点：

• 额外的间接层使对较简单情况的理解变得复杂。 （通过将数据拉到多层而不实际完成操作来实现一些琐碎的事情也很烦人。）

因此，如果输入处理混淆了用例逻辑，我将选择控制器和应用程序服务的分离。如果两者都很简单，我会选择在控制器中保留用例逻辑，以便您可以轻松地在代码用例中看到与输入处理分开的内容。