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

Question

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

Answer 1

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

所有控制器正在做的是处理来自UI的请求.它不属于应用程序域.

-1。控制器是请求/命令协调器。在六角形架构中，控制器位于应用程序服务/命令处理程序/查询处理程序的上方。控制器是请求翻译器，并与通信协议（上层）和命令/查询处理程序（来自较低层的应用程序服务）耦合。可以将控制器视为应用程序服务外观，因为它们可以翻译并准备由较低层（应用程序服务/命令查询处理程序）处理的命令/查询/消息。 (3认同)
-1 因为控制器与 DDD 无关。你把控制器放在哪里无关紧要，你可以说控制器只是消息/通信协调器，它们以两种方式耦合：用户界面和应用程序服务。您可以在没有 UI（纯命令上下文）的有界上下文中使用控制器。并且您可以有一个仅用于表示的有界上下文（一个复合业务组件，仅用于查询 2 个或更多有界上下文）。PS 控制器与 UI 的耦合度较低，它们只需要一组来自何处的请求参数。 (3认同)

Answer 2

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

如果你看 pg. 在 Evan 的 DDD 的 72 中，您会看到图 4.1 显示控制器是 UI 层的一部分。这是有道理的，因为如果 V 和 C 位于不同的层中，那么当这些层应该只通过间接和接口连接时，它们之间就会有密切的耦合。 (9认同)
@Louis，我还没有读过 Vaugn Vernons 的书，但我刚刚完成了一个成功的 DDD 项目。我只能说控制器在一个完全独立的项目中，即客户端项目。在我们的案例中，客户端是一个 MVC 前端。它可以是任何其他客户端。应用层是一个完全独立的项目，站在自己的两只脚上。它有自己的验证器，可以通过 WCF 接口提供数据。MVC 客户端中的控制器只是调用应用层的代理方法。除此之外，他们没有执行任何其他功能。 (2认同)

Answer 3

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

域服务：封装业务逻辑，这些业务逻辑自然不适合域对象，并且不是典型的CRUD操作-那些属于存储库。

应用程序服务：供外部使用者用来与您的系统对话（例如Web服务）。如果消费者需要访问CRUD操作，则可以在此处找到他们。

因此，您的服务可能是应用程序服务，而不是域服务，或某些部分应用程序服务，某些部分域服务。您应该检查并重构代码。我想四年后没关系，但是我对当前正在开发的应用程序有相同的想法。这个应用程式可能太小，无法在其上使用DDD，因此将控制器与应用程式服务混淆是过度工程的迹象。

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

Answer 4

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

优点：

缺点：

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