架构抉择之分合矩阵

“高内聚·低耦合”，已经被广大程序员们视为设计界的金科玉律。然而，应用到实际的项目中，看似浅显易懂的原则，往往变得不那么确切。我们经常会争论某个功能该不该复用；我们往往也在讨论不同业务应用的前端，到底是聚合到一个入口和一个操作界面，还是分开成不同的入口，彼此隔离。

争论的背后，或许是我们解构的还不够。

忽略基础设施，从应用架构的角度来看，一个完整的应用系统往往包括基础能力、业务应用和终端交互 3 层，而我们在考虑该复用还是独立的时候，不能仅仅用技术眼光，还需要引入业务视角。

首先，我们关照下“基础能力”。基础能力往往是企业经过精心设计、治理、沉淀下来的通用性的部分。譬如企业的客户信息管理、支付、安全风控、工单体系、客服体系等。这个层面的能力，更多是技术上的共享，业务上并没有特殊的需求。而且这部分通过共享，很容易促进企业实现“业务平台”化，最大程度的实现成本的节约、能力的挖掘和交付周期的更短化。

其次，从业务应用这个层面来看，企业往往有不同的业务点、业务线，这些业务之间往往有不同的价值链，不同的关系人。也因为业务成熟度不同，研发周期、迭代频率、研发策略都存在较大的差异性，因此，无论是从技术的灵活选择互不干扰，还是从业务上的最小化变更影响半径、最小化协调人群等，都希望各个业务之间是独立的，因此对应的业务应用也应当是彼此隔离的。

最后，我们聚焦到终端交互这一层次。与前两层不一样，这一层因为处于直接面向客户服务的最外层，也是客户可以直观感知到的一层，我们需要更多的考虑业务感受。目前主流技术方案中，有两种实现方案。其一是类似单体工程的模式，将不同业务聚合到一个前端工程，统一呈现和服务，客户只需要通过一个入口即可完成他可以操作的各类功能。缺点是没有实现业务上的独立演进，很容易一个业务的更新迭代把其他给拖累了。另一种实现方式是不同的业务不同的前端工程，客户需要通过不同的入口去使用对应的功能，存在较大的记忆负担和一定的操作障碍，如果业务线越多，负面影响也会累积的更高，因此也不是最理想的方案。

针对终端交互这个层面，比较理想的实现方案应该是技术上彼此独立，业务上让客户有集成的体验，即聚合在一起，类似单体工程的操作体验。针对这个方案的思考也越来越多，也涌现了一些不错的框架，譬如 qiankun（https://qiankun.umijs.org/zh/guide），微前端前框。

分还是合，并不是一个简单的命题，需要我们将系统层层解构，再结合技术和业务视角，或许才能得出更细粒度也更匹配的方案。