DDD：程序应用服务的 OOP 替代方案是什么？答案

【问题标题】：DDD: what are the OOP alternatives for procedural Application Services?DDD：程序应用服务的 OOP 替代方案是什么？
【发布时间】：2016-01-16 00:24:44
【问题描述】：

我最近收到了 Scott Miller 和 Nick Tune 撰写的《领域驱动设计的模式、原则和实践》一书。它在 C# 中有一些不错的示例，因此与我之前读过的其他 DDD 书籍有点不同，后者是 Java 版本。由于 C# 对委托和事件的支持，域事件实现非常简洁。

但是，有一点让我担心，正如书中应用服务一章所说，它应该是“程序化的风格和精简的”。我知道应用程序层应该是薄的，但为什么程序风格？我不想编写程序代码，否则我一开始就不会选择 DDD。我还发现这篇 stackoverflow 文章还标签应用程序服务是过程代码：

所以你看到了吗？应用程序服务在风格上是程序化的，而不是 OOP。这让我想知道我是否可以通过将应用程序服务的过程接口替换为 OO 接口来改进设计以使其更加 OO。本文建议方法对象会这样做，它是否有效？程序应用服务的更多 OO 替代方案是什么？谁能详细说明？

【问题讨论】：

【解决方案1】：

应用程序服务不是编程范式意义上的程序化服务。它是一个对象，它封装了数据（对其协作对象的引用）和行为——协调对这些协作者的调用。

它可能在精神上看起来是程序性的，因为有一系列的动作，但是当有一个应用任务意味着许多步骤时，例如：

无论编程范式如何，您都无法摆脱这种程序性/顺序性。

例如，即使您使用面向对象的责任链模式，每个步骤都由链中的单独参与者执行，您仍然需要有一个知道如何组装链的“主”对象以正确的顺序，因此根据定义知道程序，因此它是同样的程序。

【讨论】：

【解决方案2】：

OO 世界中的所有方法都是程序化的 :)

我认为作者试图传达的是将应用服务实现为操作脚本。因此，它只是将域和基础设施的各种其他位作为一组顺序调用进行协调。理想情况下，事务边界也在应用服务层处理。

也许Martin Fowler's service layer 的文章会提供更多信息。

您可能会将结构化编程与过程代码混淆:)

【讨论】：

对我来说，对对象自己的数据进行操作的方法不是程序性的，它正是对象应该是的，数据和行为的组合。如果数据和行为是分开的，它的程序性，这就是贫血域模型是程序性和反模式的原因。
除了语义之外，应用程序服务是无状态的，因此必要的数据被传递给相关的方法调用，并且任何其他数据都由该方法获取。之后进行各种调用。恐怕没有比这更OO的方法了。任何可以移动到类中的代码都应该是，但由于应用程序层在某种程度上是一个集成层，因此代表该层的任何类都将看起来是程序性的。