工程架构持续演进

前言

前面的组件化思考和落地介绍了组件化在我们项目中的大致设计，实际落地效果也不错。同时也遇到了多App业务迭代的情况，于是落地了融合开发方式-单工程多target的多App方案。

本文基于实际迭代中遇到的问题，继续分析当下存在的问题，以及对于未来迭代方向做一个梳理。

正文

整体视角

首先介绍工程当前整体设计，整体工程视角的架构图如下：

业务实现层和业务接口层，是常迭代的业务部分；

• 业务接口层，存放业务组件对外的能力，这些能力大部分用接口来表述。
• 业务实现层，存放对接口的具体业务实现，承载着业务组件的大部分逻辑。
• 业务基础层，App内通用的基础能力，通常包数据结构、App级UI组件、基础服务能力。
• 通用基础层，工程的二方库和三方库依赖，引入更多扩展能力。

组件视角

组件内部的结构设计，主体是分为对外部分和对内部分。

对外部分，其他业务组件可以依赖，整体可以分为业务接口层、服务接口层和业务基础层。

业务接口层，存放业务抽象接口、枚举、常量，封装组件业务能力；

服务接口层，存放以服务形式提供的业务能力，该服务通常是由业务组件进行维护，所以不纳入App通用的服务层。

业务基础层，存放业务对外提供的UI基础能力和数据接口，这部分UI和数据由业务业务组件进行维护，所以不纳入App通用的基础层。

对内部分，是其他业务组件不可依赖，是对外部分中业务接口、服务接口的具体实现。

问题分析

业务迭代角度

1、业务组件内存在其他业务组件逻辑，最常见的就是业务组件A因为存在部分视图、逻辑是属于业务B、业务C、业务D，于是业务组件A就在组件内直接引入组件B/C/D，长期不便于业务做权限管控和稳定性治理，同时也会增加未来迭代的理解成本；

2、业务组件对外提供的业务能力、UI组件、基础功能等，都由接口层承载，即使只是依赖组件A的某个特定功能，也要直接依赖整个组件A；

...

工程架构角度

1、接口层与实现层，基础层与实现层都有隔离，但是仍然存在同层之间相互依赖较多的情况，甚至会有UI组件、数据层依赖服务层情况；

2、多App场景，如果想要让某个App下去除某个组件，由于组件依赖较多，会导致潜在较多风险；

...

架构演进

架构演进的思路，主要考虑当下要素：

1、多App迭代述求，以融合开发方式为多App提效，同时保留业务细节差异化能力，以及整体业务模块剥离的包体积优化空间；

2、SaaS同构迭代，未来相关业务既要接入SaaS，又要迭代SaaS；

3、质量和效率提升，更加清晰的工程架构来承载复杂业务，层级之间更加清晰并有防劣化，复杂业务组件有良好设计来降低理解成本

基于上述分析和考虑，对原来架构进行进一步调整：

改动点分析

1、部分业务组件平台化，组件内部业务逻辑实现依赖反转，同时沉淀出业务的数据层和UI基础层；

2、服务层建立，架构更加清晰合理，避免基础层依赖服务层，同时也方便做依赖防劣化卡口；

3、数据治理，专注于数据逻辑，只能被上层业务引用，不依赖其他业务组件和服务层；

4、UI基础层搭建，业务UI基础能力沉淀，可以依赖只能被上层业务引用，不依赖其他业务组件和服务层；

5、业务基础库和通用基础库分隔，业务基础库只服务于当前工程，通用基础库服务于类SaaS的多宿主；

6、配合多包SOP调整差异化组件，将大部分固定差异用配置化的方式进行处理；

总结

架构演进是一件需要持之以恒的事情，要权衡好其中的效率提升和维护成本。

架构不是越复杂越好。越多的层级固然能更好做逻辑拆分、依赖隔离，但是也有更多的开发能力和理解能力要求。

如无必要，勿增实体。