特别说明：本篇文章是我们开发小组的一位北京大学计算机博士大哥，分享到我们组内部的，在此感谢大哥！
近期，我结合应用程序梳理了一遍某中间服务的应用架构，该文是本人对中间服务应用
现有架构的认识，并针对该架构存在的问题表述了对其重构或优化的方案。
如图 1 所示，中间服务应用采用分布式微服务架构。技术平台在集成 dubbo 分布式框架的时，为了对现有平台产生较小的侵入，平台抽象出一个“接口适配层”，开发人员无需关注该层，仅需针对具体业务开发相应的“伪”服务层， 此处的设计思想毋庸置疑。问题就出现在图 1 中的“伪”服务层（抱歉！是本人给该层的定义），单纯从架构图是看不出其任何问题的，需结合代码才会暴露出问题。“伪”服务层的用户上下文，即其接口的出入参数与厂商的商业技术平台高度耦合，这是一个非常严重的问题。试想，我们的核心业务逻辑写在该层，如今后技术平台升级或更换技术平台，势必会造成高昂的开发维护成本，后果可以说是灾难性的。其次，因“伪”服务层高度依赖技术平台的用户上下文，数据的存取均使用该上下文，这将会丢失应用系统最有价值的领域模型。此外，服务接口不仅仅是提供给第三方系统接入调用，进程内服务之间的接口调用也是很常见的，这种场景难道也需要调用方构造用户上下文吗？怎么会呢！这势必会在很大程度上降低服务接口的复用率。控制层也好，接入层也罢，也许二者是对“伪”服务层最好的定义，我们怎么会在控制层或接入层编写核心业务逻辑呢？最后，对第三方应用的调用，没有实现良好封装，此处可以效仿 DOA，抽象出外部接口层（POJO），其作用不言而喻。
鉴于上述问题，我们可以对“伪”服务层重构，分别拆分出上下文转换层与服务层，同时
抽象出访问第三方应用的 API 层，重构后的应用架构如图 2 所示。注：出于架构图视觉考
虑，第三方应用模块也画在了中间服务架构中，未区分系统边界，有悖设计原则，见谅！但
愿瑕不掩瑜～
正如上图所示，重构后的“伪”服务层只负责交易的转发控制及数据合法性校验；服务层
负责实现核心业务逻辑，解耦其对商业技术平台的依赖，对上下文转换层提供 POJO 式的
API，在该层，核心领域模型会水到渠成；上下文转换层负责用户上下文与服务层 API 出入
参数的转换，该层与“伪”服务层在将来的技术平台升级或技术平台更换时是可抛弃的，理想
情况下，服务层几乎不会受到任何影响，可以很大程度上降低后期的开发及测试成本。