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