28

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

4

4 回答 4

15

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

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

于 2013-09-05T17:00:18.780 回答
15

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

领域驱动设计：领域服务、应用服务

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

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

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

于 2017-02-09T02:18:18.557 回答
6

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

于 2013-09-07T13:20:08.340 回答
6

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

优点：

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

缺点：

  • 额外的间接层使对简单案例的理解变得复杂。（通过通过许多层提取数据而不实际做任何事情来实现一些琐碎的事情也很烦人）。

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

于 2019-08-18T15:27:17.537 回答