控制器可以作为DDD中的应用服务层吗？

Question

在ASP.NET MVC世界中，控制器可以充当应用程序层，调用我的域对象和服务来完成工作（假设控制器只是严格调用域而不执行任何操作）。在处理的特定情况下，我需要建模的应用程序流逻辑非常少，因此我正在考虑取消应用程序层并直接从控制器内调用域。

这是一种公平的方法吗？

Answer 1

我猜你的意思是你的业务逻辑是使用Domain Model模式实现的。在这种情况下，应用程序层应该非常简单，并且根据定义它不应该托管任何业务逻辑。所有业务逻辑都应该驻留在域层中;应用程序层中的方法应类似于以下步骤：

1. 加载聚合的实例
2. 执行操作
3. 保留更新后的汇总
4. 返回对用户的回复

如果您只是在应用程序层中执行此操作，我认为没有理由不将其放入控制器中。

另一方面，如果您的域模型贫乏，并且您在应用程序层中确实有业务逻辑，那么我更愿意引入一个单独的层。

Answer 2

将您的MVC控制器视为您的DDD应用程序层将会出现一些负面情况。

最大的一点是，您的应用程序层（关于DDD）是您为域/业务流程建模的关键位置之一。例如，您可能在应用程序服务中有一个名为：

的方法

PayrollService.CalculatePayslips();

这可能涉及为当前活跃员工检查域服务或外部系统，然后可能需要查询其他域服务或外部系统的缺勤，退休金扣除等。然后需要调用域服务（或实体）进行计算。

如果您想触发从系统中其他位置计算工资单的任务，那么在MVC控制器中捕获这样的域/业务逻辑会导致体系结构问题。此外，如果您希望将此过程公开为Web服务，或者甚至是从另一个MVC控制器公开，那么您的引用将会跨越或上升到您的表示层。类似这些＆＃34;的解决方案可能会起作用，但它们会为您的应用程序成为Spaghetti Code或Big Ball of Mud（这两种代码都具有建筑意义）。您可能会导致循环引用和高度耦合的代码，从而增加维护成本（包括时间，金钱，开发人员的理智等）。

最终，软件开发是一场权衡游戏。架构问题变得越来越重要，应用程序的增长也越大。对于很多非常小的CRUD应用程序，架构问题可能是微不足道的。 DDD的关键目标之一是解决复杂性，因此可以认为大多数DDD项目应该具有足够的复杂性来关注良好的企业架构原则。

Answer 3

我不会这样做。

为应用程序服务创建单独的类然后从控制器调用它的工作量很小。只有在构建应用程序时才会产生成本。

但是，由于业务层和表示层之间的高度耦合，一旦开始维护应用程序，您必须支付的价格要高得多。

在确保应用程序中separate different concerns时，测试，重用，重构等要低得多。