领域服务的定义

在最初的元模型定义里，领域服务让不少人纠结，一个经典的例子是在账户管理领域里对“转账”这个业务行为的抽象。由于转账本身是作用在至少两个账户上的，所以把转账作为一个账户的行为显然是不合适的。那么如果我们把转账名词化抽象成一个实体呢？感觉也是比较别扭，毕竟转账是依附于账户存在的。

这个时候DDD在元模型里提出了服务（Service）这个抽象，转账被抽象为一个服务感觉就顺畅多了。同样道理，在我们上面的订单跟踪领域里，如果跟踪的过程中需要进行短信的通知，一个比较好的建模就是抽象出一个“通知”服务来完成。

我经常会用静态方法来帮助技术人员理解服务的抽象（虽然服务并不一定用静态方法来实现）。服务本身就像一个静态方法一样，拥有一定的逻辑但不持有任何的信息，从整个领域来看也不存在不同“版本”的同一个服务。

一个经常困扰大家的问题是对Service这个词语的限定，有的分层架构设计里会出现领域服务（Domain Service）和应用服务（Applicaiton Service）。大多数时候应用服务在领域服务的上层，直接对外部提供接口。如果存在这样的分层，那么领域服务就不应该直接对外，而应该通过应用服务。

举个例子，前面的订单消息通知如果是一个领域服务，在完成订单状态变化时创建通知消息，而最后的通知以短信的方式发给设定的人群，这样就应该有一个相应的应用服务，包含了具体的业务场景处理逻辑。之后也可能有一个邮件通知的应用服务，同样调用了这个通知领域服务，但通过邮件渠道来完成最终的业务场景。

由于微服务架构的流行，每个子领域的粒度已经相当细了，很多时候已经没有这样的领域服务和应用服务的区分了。当然从简单性角度出发这是好事情。在整个建模过程中，服务的抽象往往是最不确定的，也是最值得大家反复斟酌的地方。