按照业务拆分
- 可能同时存在多个系统,每个系统都代表自己的业务
- 它们之间的关联可能并不是很紧密,对于前端应用来说,只需要一个系统内对象的ID,加上用户的Token,便能轻松从一个系统跳转到另外一个系统中
- 如果业务间本身的耦合就比较严重,那么要从前端业务上分离它们,就不是很容易
按照权限拆分
- 对于一个同时存在多种角色及多种不同权限的网站来说,最容易采用的方案就是通过权限来划分服务和应用
- 是否按照权限来划分应当取决于应用是否臃肿,或者是否正在变得臃肿,导致难以维护,还需要考虑是否为每种角色和权限划分出不同的前端应用
按照变更频率拆分
- 在一个前端应用中,并非所有模块和业务代码都在不断地修改、添加新的功能,不同的业务模块拥有不同的变更频率
- 若是将应用中频繁变更的部分拆分出来,不仅更容易维护其他部分的代码,还可以减少频繁的业务修改给其他部分带来的问题
- 使用变更频率进行拆分的前提是,我们使用数据统计来计算各部分的使用情况
按照组织结构拆分
- 团队的组织方式必然会对它产生的代码有影响,根据不同团队来划分不同的微前端应用及服务
- 与业务划分方式稍有区别,一个团队可能维护多个业务
- 对于跨团队协作来说,集成永远都是一个复杂的问题,尤其在团队本身是异地开发的情况下,沟通就变成一个麻烦的问题
跟随后端微服务拆分
-
与微架构相关的实施,并不只有前端才有,往往是后端拥有和相应的实施,前端项目才会进行进一步的拆分
-
然而后端采用的拆分方式,并不都适合于前端应用,可能多数时候不适合
-
后端可能采取聚合关系来划分微服务,这时对于前端应用来说并没有多大的启发