什么是领域服务(首先，什么不是领域服务）
当我们在软件开发领域中听到“服务”这个词时，自然地我们可能会想到一个远程客户端与某个复杂的业务系统交互的场景，该场景基本上描述了SOA (4)中的一个服务。有多种技术和方法可以实现SOA服务，最终这些服务强调的都是系统层面的远程过程调用(RPC)或者面向消息的中间件(MoM)。这些技术使得我们可以通过服务与分布在不同地方的系统进行业务交互。
以上这些都不是领域服务。
另外，请不要将领域服务与应用服务混杂在一起了。在应用服务中，我们并不会处理业务逻辑，但是领域服务却恰恰是处理业务逻辑的。如果你还是不明白它们之间的区别，请参考应用程序(14)。简单来讲，应用服务是领域模型很自然的客户方，进而也是领域服务的客户方。在本章后面，我们将对此进行演示。
虽然领域服务中有“服务”这个词，但它并不意味着需要远程的、重量级的事务操作1.
1. 有时，当与另一个限界上下文交互时，领域服务的确需要进行远程操作，但此时我们关注的并不是将领域服务作为一个服务提供方,而是将其作为RPC的客户端 ↩
领域模型中的服务的确是一种非常好的建模工具。现在，我们已经知道领域服务不是什么了，那么，它到底又是什么呢？。
有时，它不见得是一件东西……当领域中的某个操作过程或转换过程不是实体或值对象的职责时，此时我们便应该将该操作放在一个单独的接口中，即领域服务。请确保该领域服务和通用语言是一致的；并且保证它是无状态的。[Evans, pp. 104, 106]
通常来说，领域模型主要关注于特定于某个领域的业务，同样，领域服务也具有相似的特点。由于领域服务有可能在单个原子操作中处理多个领域对象，这将增加领域服务的复杂性。
那么，在什么情况下，一个操作不属于实体(5)或者值对象呢？要给出一个全面的原因列表是困难的，这里我罗列了以下几点。你可以使用领域服务来：
- 执行一个显著的业务操作过程。
- 对领域对象进行转换。
- 以多个领域对象作为输人进行计算，结果产生一个值对象。
需要明确的是，对于最后一点中的计算过程，它应该具有“显著的业务操作过程”的特点。这也是领域服务很常见的应用场景，它可能需要多个聚合作为输入。当一个方法不便放在实体或值对象上时,使用领域服务便是最佳的解决方法。请确保领域服务是无状态的，并且能够明确地表达限界上下文中的通用语言(1)。