DDD之Service革命

一、传统架构下的Service

1.1 SSH时代

到目前为止还好，曾经用过SSH框架，那时候不懂分层，前后端还不分离。当然，走出校园之后SSH就没有碰过了。在SSH中使用struts action做控制层路由，hibernate做持久化。spring 做bean容器，最后的业务就是在一个项目工程中由struts action类到service bean然后到hibernate dao就可以了。

1.2 MVC时代

在MVC框架思想中MVC基本上代表了前后端之间的桥梁，服务层依然在幕后操作。但是mybatis这样的新兴ORM框架以及缓存组件等都慢慢兴起。到后期前后端分离大潮来临的时候服务层仍然没有做过多演化。
这里只是在面对复杂逻辑的时候从页面路由落到后段路由，基于页面模型，视图模型，数据库模型进行适配融合。所以service仍然是一层。具体表现就是Controller or Action or Servlet 会直接调用com.xx.xx.service中的接口。

二、微服务下的Service

在微服务大行其道的时候，service呈现的景象就不一样了，尤其是RPC的冲击。在dubbo等自研rpc框架出现之后跟前端就没什么关系了，tomcat和http则需要另起服务去对接RPC接口，web服务成了一个路由服务，或者空壳服务。前端的逻辑更少，service直接就在rpc的实现层搞定就行了。基于springboot/cloud的技术体系仍然跟MVC时代差不多。

三、DDD下的Service

3.1 两层服务

前面两节做了简单的介绍，service仍然是那个service,但是其本质就是比较厚重，比较冗余。当业务复杂，垂直业务与横向服务一起导致service变得更加无法维护。值得欣慰的是由于前后端协作方式的变化，后端只需要解决service 服务的问题。
经过一段时间的研究，发现很多相对复杂的业务服务工程，如营销平台，交易服务等这些其实有着两层服务层。从COLA架构中可以看到service主体由facade(dubbo client)+domain gataway完成。也就是说应用层被从service中拆出来了，这个变化让人感觉到在复杂的业务逻辑中还能呼吸。让容易变化的业务拆出来，服务层服务只做自己。

3.2 CQE服务

现在我们转移一下视角，来看DDD的相关分层架构体系。有大佬提出了CQE这个名词，我觉得不错，但是还需要进一步确认一下，CQE到底是啥？这里的CQE其实跟CQRS颇有渊源。C代表Command,Q代表Query,E代表Entity。但是从CQRS体系看E也代表着Event，就是基于事件源的一种新的CQRS变体。经过最近的研究在COLA 中app层中把command,query作为子包融入进去了，但是command背后其实还有executor，所以这里的E也可以指代COLA中的Executor。

那么现在我们看服务其实就会发现Service不再负责CURD了，Service也不再校验参数，直接被应用层调用了。经过分离之后，Service变得丰富多样。在比较老的时代里我们可以通过设计模式让Service看起来井井有序，但是现在，Service通过更细致的分层划分，分包治理中显得更加专业也职责单一了。
从全局视角来看Entity分了实体和值对象，包括那些有业务意义的配置数据，枚举数据。虽然数据库模型跟Entity基本上会对不上，但是关注点已经不在数据库模型了。那么在Service层中也将不是直接调用DAO，调用缓存调用上下游服务那么简单了。总结一下：

1. 基于CQRS模式，应用层大部分逻辑可以通过xxxExe来跟领域服务打交道。
2. 领域服务中存在factory,repository等接口作为特化的gataway存在
3. 根据第二点来说Entity也更加丰富，具有代表整体子业务功能的聚合根，这里service不再直接引用底层的xxxDAO了
4. 在调用下游接口中我们为了防止下游接口的变动导致领域服务不稳定而做了一些包装适配，这里仍然可以看作service的一种扩展模式。在service中体现的变化就是我调下游服务就像调自己服务一样。
5. 其他诸如query,mq,cache这些当然都在跟service划分界限，不要这么直接调用我，我不喜欢。

3.3 扩展点服务

我曾经非常有幸在一家顶级互联网公司工作过，见识过更为复杂的业务逻辑。在分层中也看不清楚到底有多少层，那么有着多条业务线，多个业务场景的情况下如何保证代码持续稳定，持续支撑新业务呢？当前DDD已经可以通过两层服务搞定多业务线多场景问题，那么为什么还这么复杂呢？其中一点就是在中台平台建设与业务发展之间有个速度差，说白了就是中台平台建设太慢了。分了多业务线多场景依然无法快速支持业务交付，哪些是我中台平台的核心能力，哪些是我的扩展能力，哪些是业务定制能力都将不再清晰。这些能力建设全部让中台平台的人承担明显不够。当前通过不同业务线分包，不同业务场景分应用层服务，但是仍然会把服务层搞乱，因此很多大佬决定从业务架构上入手。对service层做深入治理，定制业务扩展点，理论上可以无限扩展。

通过业务框架对service进行治理之后，通过扩展点来扩展业务定制逻辑，领域内核心逻辑和领域扩展逻辑再也不跟业务线业务场景混搭了。

四、展望

4.1 服务层编排

目前云原生非常火，服务编排也显得非常时髦，那么对于service来说有什么影响呢。从单体服务到微服务，到分布式，然后云原生一路走来其实都在迁就service的发展。因为流量多了，业务多了，service也更复杂了，要执行service就要更多资源扩展，治理。

目前很多中间件都在向docker化，mesh化迈进，目的就是希望service能快速交付快速执行，由于互联网用基数很大，服务发布迭代要做到影响最小，那么技术上的东西都要跟service划分界限。写service的人只要保证符合业务逻辑，处理及时即可。但是如何让service上去，技术上就要做更多工作。比如微服务拆，拆的一个核心问题就是service都在一起了，过得不开心。拆了之后要怎么协调，多了节点要怎么运维，依赖多了要怎么治理，这些都是由service引起的。
服务层编排就需要解决service在拆分之后如何协调跨节点跨集群的分层问题。当然，其他应用场景就是在规模做大之后服务层已经形成了自我管理的能力，通过low code就可以做到我新业务快速接入已有能力的情况。

4.2 Serverless与Service

现在的技术生态已经逐步扩展到多集群，多中心单元架构上了，在整个后端的业务逻辑中有很多时候我们是在处理技术问题，包括缓存，消息，数据库等。一个直观的感受就是在运维方面智能化运维确实释放了运维的大部分压力。另外一方面广大程序员也将专注于写业务逻辑而不用考虑包的兼容性，框架的版本，中间件的部署等。目前的serverless虽然跟service 没有直接的关系但是最终的趋势就是serverless会将service依赖的技术组件，包括含有状态的业务信息完全消除掉。比较理想的情况就是我只需要写业务服务基于简单的服务容器就可以利用serverless和云的能力实现服务驱动。