控制器可以充当DDD中的应用程序服务层吗？

在ASP.NET MVC世界中，控制器可以充当应用程序层，调用我的域对象和服务来完成工作（假设控制器只是严格地调用域并且什么都不做）。在特定情况下，我正在处理的应用程序流逻辑非常少，因此我正在考虑取消应用程序层并直接从控制器中调用域。控制器可以充当DDD中的应用程序服务层吗？

这是一个公平的方法吗？

来源

2017-01-04 Karthik Balasubramanian

只要你了解你的设计的含义，就没有关于你可以做什么和不可以做什么的明确规则。它总是归结为成本 - 收益的权衡。在这种情况下，简单性会损失灵活性。例如。如果你有多个用户界面，该怎么办？如果外部系统必须与您的应用程序进行交互会怎样我通常更喜欢立即添加额外的间接层，因为它不是那么好，并且可以为您节省大量的重构。 – plalx

人们过于专注于这些设计模式。他们是模式，因为他们解决的问题非常普遍，很多人一次又一次地做同样的事情。但是，并非每个应用程序都需要每种模式根据应用程序的需要设计应用程序，并停止担心是否检查设计模式清单中的所有框。 –

@plalx：现在添加额外的间接层现在看起来对我来说太过矫枉过正，但我完全理解你的情况。我们很乐意知道引入另一层的成本会带来成本。 –

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

最大的问题是您的应用程序层（关于DDD）是您为域/业务流程建模的关键位置之一。例如，您可能会在应用服务都称为一个方法：

PayrollService.CalculatePayslips();

这可能包括，检查当前在职职工域服务或外部系统，它可能然后需要查询其他域的服务或外部系统缺勤，退休金扣除等。然后需要调用域服务（或实体）来进行计算。

在MVC控制器中捕获像这样的域/业务逻辑会导致架构问题，如果您想触发系统中其他地方计算工资单的任务。此外，如果您曾想将此过程作为Web服务公开，或者甚至是从另一个MVC控制器公开，那么您将有参考文件穿过或进入您的表示层。像这样的解决方案“可能有用”，但它们将有助于您的应用程序变成意大利面条代码或泥浆大球（在建筑意义上都是代码气味）。您有可能导致循环引用和高度耦合的代码，这会增加未来的维护成本（包括时间，金钱，开发人员的理智等）。

在一天结束时，软件开发是一个折衷的游戏。建筑问题成为更大的问题，您的应用程序越来越大。对于很多非常小的CRUD应用程序，架构问题可能可以忽略不计。 DDD的关键目标之一是处理难度复杂度，因此可以认为，大多数DDD项目应具有足够的复杂性来关注良好的企业架构原则。

来源

2017-01-05 09:00:24

我听到你的关注，但是我是YAGNI的忠实粉丝，目前据我所知，我的控制器不需要应用程序逻辑。在我看来，创建一个应用程序层仅仅是因为我可能需要它在功能上，或者因为这是正确的做法，并不适合我。但是我很欣赏你的观点，它确实重申了对应用服务的需求（我们需要它们） –

公平不够，架构决策取决于很多事情，它总是一种平衡行为。如果它是你自己的应用程序（只是你开发它），它的体积很小，不会增长（或者它的寿命很短），并且没有其他开发人员需要维护它，那么使事情变得更复杂可能没有任何好处比他们需要的要多。 –

还有单元测试需要考虑。单元测试控制器通常比一套类库方法更难。再次，如果你只是在试验，编写一个小应用程序等，你可能会发现单元测试你的代码没有任何好处。 –

-2

我不会这样做。

为应用程序服务创建单独的类然后从控制器调用它的工作量很小。当您构建应用程序时，成本也仅限于此。

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

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

来源

2017-01-05 10:37:09 jgauffin

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

负载情况下执行动作
坚持了更新的聚合
返回响应用户

如果是这样的所有你在应用层做的事情，我没有理由不把它放在控制器中。

另一方面，如果你的领域模型是贫血的，并且你在应用层中有业务逻辑，那么我宁愿引入一个单独的层。

来源

2017-01-10 14:12:09 Vladikk

控制器可以充当DDD中的应用程序服务层吗？

回答

相关问题