“高内聚·低耦合”,已经被广大程序员们视为设计界的金科玉律。然而,应用到实际的项目中,看似浅显易懂的原则,往往变得不那么确切。我们经常会争论某个功能该不该复用;我们往往也在讨论不同业务应用的前端,到底是聚合到一个入口和一个操作界面,还是分开成不同的入口,彼此隔离。
争论的背后,或许是我们解构的还不够。
忽略基础设施,从应用架构的角度来看,一个完整的应用系统往往包括基础能力、业务应用和终端交互3层,而我们在考虑该复用还是独立的时候,不能仅仅用技术眼光,还需要引入业务视角。
首先,我们关照下“基础能力”。基础能力往往是企业经过精心设计、治理、沉淀下来的通用性的部分。譬如企业的客户信息管理、支付、安全风控、工单体系、客服体系等。这个层面的能力,更多是技术上的共享,业务上并没有特殊的需求。而且这部分通过共享,很容易促进企业实现“业务平台”化,最大程度的实现成本的节约、能力的挖掘和交付周期的更短化。
其次,从业务应用这个层面来看,企业往往有不同的业务点、业务线,这些业务之间往往有不同的价值链,不同的关系人。也因为业务成熟度不同,研发周期、迭代频率、研发策略都存在较大的差异性,因此,无论是从技术的灵活选择互不干扰,还是从业务上的最小化变更影响半径、最小化协调人群等,都希望各个业务之间是独立的,因此对应的业务应用也应当是彼此隔离的。
最后,我们聚焦到终端交互这一层次。与前两层不一样,这一层因为处于直接面向客户服务的最外层,也是客户可以直观感知到的一层,我们需要更多的考虑业务感受。目前主流技术方案中,有两种实现方案。其一是类似单体工程的模式,将不同业务聚合到一个前端工程,统一呈现和服务,客户只需要通过一个入口即可完成他可以操作的各类功能。缺点是没有实现业务上的独立演进,很容易一个业务的更新迭代把其他给拖累了。另一种实现方式是不同的业务不同的前端工程,客户需要通过不同的入口去使用对应的功能,存在较大的记忆负担和一定的操作障碍,如果业务线越多,负面影响也会累积的更高,因此也不是最理想的方案。
针对终端交互这个层面,比较理想的实现方案应该是技术上彼此独立,业务上让客户有集成的体验,即聚合在一起,类似单体工程的操作体验。针对这个方案的思考也越来越多,也涌现了一些不错的框架,譬如qiankun(https://qiankun.umijs.org/zh/guide),微前端前框。
分还是合,并不是一个简单的命题,需要我们将系统层层解构,再结合技术和业务视角,或许才能得出更细粒度也更匹配的方案。
联系客服