前文介绍了某中间服务应用系统在应用架构方面存在的严重不足，即应用程序未进行合
理的分层，所谓的“服务层”与商业技术平台高度耦合，并且丢失了应用系统最有价值的领域
模型等设计缺陷，为今后应用系统的快速、持续迭代造成诸多问题。前文还针对所述的架构
缺陷，介绍了应用架构的整体重构方案，但未涉及具体的重构细节，该续文将介绍应用架构
的重构细节及重构过程。
如图 2 所示，重构后的应用分为交易接入层与核心业务逻辑层，这两层均为独立的项
目工程（可分别有不同的团队开发维护，初级工程师负责接入层开发，中高级或资深工程师
负责业务逻辑层开发），交易接入层项目依赖业务逻辑层项目，前者强依赖技术平台，后者
对技术平台弱依赖，后者各模块除通讯模块外，其它各模块均为 POJO 实现，仅允许少量
依赖开源框架或类库，通信模块可依赖商业技术平台 API 与第三方应用系统交互。如今后
升级技术平台，理想情况下，核心业务逻辑各模块几乎不会受到影响。
图 1 中，将原来的“服务层”定义为交易接入层，增加了接口适配上下文转换、服务、系
统产品、产品功能、外部接口、外部接口适配等模块，各模块协作完成交易处理。在交易接
入层，原则上不允许有数据库及外部系统接口的访问操作，所有业务逻辑均在服务模块实现；
系统产品模块，是对应用系统中诸如理财、基金、存款等业务产品的抽象；产品功能是对产
品操作行为的抽象，比如对理财的查询、购买、赎回等操作均视为理财产品上的功能，显然，
产品和产品功能是一对多对关系，即一个产品上可以有多个功能或操作；外部接口模块，
POJO 实现，封装了产品功能模块所需的 API；接口适配模块，对接口模块提供 POJO 式
API，同时封装了技术平台的对外通信模块，屏蔽通信协议细节。核心业务逻辑层各模块的
运行时序如图 2 所示。
此外，本文介绍的应用架构，只代表分布式系统中某一具体的微服务架构，其它微服务
或子系统均遵从该架构规范。该文在前文的基础上，介绍了某中间服务应用系统的架构重构细节及重构过程。