业务单元的三种组合方式：单一、组合、通用

[[业务单元限界上下文向前端延伸出的天然独立单元]]并不是只有”一个微前端配一个微服务”这一种固定形态，根据业务目标不同，微前端和微服务可以有三种组合方式。单一业务单元是最基础的形态，一个微前端和一个微服务依托同一个领域模型，分别完成前端页面逻辑和后端业务逻辑，两者集成后对外提供服务。组合业务单元是一个微前端对接多个微服务，用于中台有多个微服务、但需要保证前端业务逻辑完整性的场景——微前端负责把多个微服务的能力组织成一套连贯的页面和操作，但这种组合有明确的风险边界：如果一个微前端对接的微服务数量过多，它会退化回一个大而全的单体前端，重新失去微前端本该有的独立部署、独立扩缩容能力，所以书中特别提醒不宜与过多微服务组合。通用业务单元则相反，是一个微前端对接一个或多个通用中台微服务，服务于那些天然需要跨领域复用的能力，比如订单、支付这类几乎每个业务领域都要用到的通用微服务，对应的通用微前端页面（如订单页、收款页）会以常驻入口的形式，被其他业务单元的微前端页面共享调用，完成跨领域的企业级业务流程协作。三种组合方式的共同前提是业务单元之间要避免功能交叉产生耦合，否则会连带影响到各自独立开发、测试、部署的边界。

结构图：

flowchart TB
  A["单一业务单元<br/>1个微前端 + 1个微服务<br/>同一领域模型的前后端配对"]
  B["组合业务单元<br/>1个微前端 + 多个微服务<br/>用于保证中台前端业务逻辑完整性<br/>⚠️ 微服务过多会退化成单体前端"]
  C["通用业务单元<br/>1个微前端 + 1或多个通用中台微服务<br/>如订单/支付，被多个业务单元共享复用<br/>常驻前台主页面入口"]