一、微前端的业务划分方式
以下几种方式是常见的划分微前端的方式：
- 按照业务拆分
- 按照权限拆分
- 按照变更的频率拆分
- 按照组织结构拆分
- 跟随后端微服务划分
1. 按照业务拆分
在大型的前端应用里，往往包含了多个业务。这些业务往往在某种程度上存在一定的关联，但并非是强关联。比如常见的电商系统的相关业务。 一个相对完整的电商系统一般拥有：
- 电子商务系统
- 库存系统
- 产品目录系统
- 物流系统
- 订单系统
- 发票系统
- ...
每个系统都代表自己的业务，它们之间的关联可能并不是很紧密————对于前段应用涞水，只需要一个系统内对象的ID,加上用户的 Token ，便能轻松地从一个系统跳转到另外一个系统中。 这种业务本身的高度聚合，使得前段应用的划分也变得更加轻松。
如果业务间本身的耦合就比较严重（如一个电子商务的运营人员，可能需要同时操作订单、物流等多个系统），那么要从前端分离它们，就不是很容易了。
因此，对于由业务性质决定的应用，往往只能依据业务是否隔离开进行拆分。
2. 按照权限拆分
对于一个同时存在多种角色及多种不同权限的网站来说，最容易采用的方案就是通过权限来划分服务和应用。尤其这些权限在功能上是分开的，也就没必要集中在一个前端应用中。
在一个带后台管理功能和前台展示页面的网站里，它们的功能有时候是绑定在一起的，如各种 CMS 、博客应用 WordPress；而在一些大型系统中，它们往往又是独立的， 有独立的入口来访问后台，有独立的入口来访问前台。多数时候，这取决于大部分用户是否同时拥有两种权限？如果只有管理员拥有后台权限，那么分开是一种更好的选择。因此， 多数应用会在项目创建的初期将管理系统划分出去。
但是对于初始时期的管理来说，往往不会有这种划分方式。为了方便管理人员使用，它们需要结合在一起。可是随着后台管理的功能越来越多，应用会变得越来越臃肿。特别在单页面 应用中，出于组价复用等目的，往往会将其设计在同一个前端工程中。
是否按照权限来划分应当取决于应用是否臃肿，或者是否正在变得臃肿，导致难以维护。还需要考虑是否为每种角色和权限划分出不同的前端应用。如果只有一种权限的功能比较高，而其他 权限业务少，那么是否就只拆分成前台和后台两部分。
3. 按照变更的频率拆分
在一个前端应用中，并非所有模块和业务都在不断地修改、添加新的功能。不同的业务模块拥有不用的变更频率。有些功能可能在上线之后，因为用户少而几乎不修改；有些功能则可能为了 做而做，即证明有这个技术能力，或者有这个功能。而有一些功能，因为是用户最常用的，所以在不断迭代和优化中。因此，可以依照变更频率来拆分前端应用。
不常用的功能，虽然业务少、变更少导致代码也相对较小，但是因为非核心业务数量多，从应用中拆分出去也更容易维护。
经常变更的业务也可以进一步的拆分————拆分成更多的前端应用或者服务。使用变更的频率进行拆分的前提是，我们使用数据统计来计算各部分的使用情况。对于一个大型的前端应用来说，这 部分几乎是不存在的问题的。
4. 按照组织结构拆分
团队的组织方式必然会对它产生的代码有影响，既然如此，就会存在一种合理的微前端划分方式，即根据不同团队来划分不同的微前端应用及服务。
对于后端来说，按照组织结构拆分服务，几乎是一个默认的做法。团队之间使用 API 文档和契约，就可以轻松地进行协作。对于前端应用来说，同样可以采用这种方式进行。
这时，作为架构的提出方和主要的核心技术团队，我们需要提供微前端的架构方案。如使用路由分发式微前端，需要提供一个 URL 入口；使用前端微服务化，需要提供一个 API 或者接入方式， 以集成到系统中。
值得注意的是，它与业务划分方式稍有区别，一个团队可能维护多个业务。如果某些业务是由一个团队来维护的，那么在最开始的阶段，他们可能倾向于将这些业务放在同一个应用中，然后， 由于业务的增多或者业务变得复杂，则会进一步拆分成多个应用。
对于跨团队协作来说，集成永远都是一个复杂的问题。尤其在团队本身是异地开发的情况下，沟通就变成一个麻烦的问题。技术问题更适合于当面讨论，如指着代码或者页面进行讨论。一旦有 一方影响了系统构建，就需要优先去解决这个问题。
5. 跟随后端微服务划分
如果后端也是微服务架构，前端也可以追随后端的拆分方式。
然而，后端采用的拆分方式，并不都适合于前端应用————可能多数时候都不适合。如后端可能采取聚合关系来划分微服务，这时对于前端应用来说并没有多大的启发，但是有些时候还是可以直接 采用一致的拆分模型。毕竟如果在后端服务上是解耦的，那么在前端业务上也存在一定解耦的可能性。