微服务的边界、数据视图与微前端

# 微服务的边界、数据视图与微前端

合并整理三讲：边界（15）、视图（16）、前端设计（17）。这三讲讲的都是"落地之后怎么不走样"。

很多团队拆微服务的方式是：把单体的一个软件包按功能拆成几个包，各自部署——搞定！但包内还是三层架构，代码高度耦合，逻辑边界不清。这叫小单体微服务。

它的结局是可预见的：随着需求膨胀，某天要把部分功能拆出去或和别的服务重组时，才发现每个"微服务"内部还是一团乱麻，只能再来一轮痛苦重构。辛辛苦苦好多年，一夜回到解放前。

根因：只定义了一个维度的边界（服务之间的物理边界），漏掉了服务内部的边界。

微服务是否设计合理，就看一条标准：架构演进（拆分/重组）时成本高不高。Martin Fowler 说微服务的重要特征是"演进式架构"——支持增量的、非破坏性的变更。

边界清晰的服务，演进就是搬聚合包；边界不清的服务，演进就是重写。

另外，聚合不一定都要拆成微服务。逻辑边界和物理边界不必强行一致——管理能力（CI/CD、运维、监控）跟不上时拆太细就是灾难。先把逻辑边界划清楚，等有能力了随时可以拆，这才是从容的姿势。

微服务内部的服务类型，从下往上：

仓储服务（基础层）→ 实体方法/领域服务（领域层）→ 应用服务（应用层）→ Facade（接口层）

三种调用场景：

微服务内跨层调用：前端 → API 网关 → Facade → 应用服务 → 领域服务 → 实体方法 → 仓储。特例：查缓存/文件这类没啥领域逻辑的操作，应用服务可以直接调仓储，跳过领域层
微服务之间调用：应用服务对应用服务（直连或走网关），涉及跨服务写操作要注意分布式事务
领域事件驱动：微服务内走事件总线，微服务间走消息中间件，异步解耦

严格分层 vs 松散分层，再强调一次：松散分层图省事（下层服务直接暴露给任意上层），但核心逻辑容易泄漏、服务变更时找不全调用方。推荐严格分层 + 逐层封装。

完整流转：

数据库 ←PO→ 仓储转换 ←DO→ 领域层/应用层 ←DTO→ 接口层(Assembler转换) ←VO→ 前端页面

为什么要这么多对象来回转换？每层的关注点不同：PO 迁就表结构，DO 迁就业务模型，DTO 迁就传输和隔离，VO 迁就展示。嫌麻烦把 PO 一路用到前端的项目，最后都会变成"改个表字段全链路震动"。

后端微服务化之后，如果前端还是一个单体大前端，前端团队要对接所有中台团队、集成成千上万的 API——沟通成本和出错概率都是灾难。

微前端就是把微服务思想搬到前端：按领域模型和微服务边界拆分前端页面，每个微前端独立开发、部署、运维，只负责特定业务单元的 UI。

一个中台团队负责一个业务单元（微前端 + 对应微服务，前后端已集成），对外提供的是"从页面到逻辑自包含"的业务组件。三种组合形态：

保险集团要在一个前端卖寿险、财险所有产品，不同产品页面要素、规则差异很大。解法是借鉴电商订单模式：

选商品（商品目录微前端）→ 录单（各产品的出单微前端，按路由动态加载）
→ 加购物车（购物车微前端）→ 生成订单（订单微前端）→ 支付（支付微前端）
→ 投保微服务把订单里的投保单转成保单

1
2
3

用户全程感觉在一个应用里操作，实际背后是一堆独立部署的业务单元在轮流上台。前端融合，后端解耦。

上次更新: 2026/10/08, 03:22:29