前端工程化 - 模块化中的边界 - MT

模块化中的边界

模块边界 本质上是变化的隔离带,一个边界是否合理, 取决与这个变化会不会被限制在边界之内

什么不是边界

• 一个文件夹 = 一个边界 ❌
• 一个 npm 包 = 一个边界 ❌
• 一个微前端应用 = 一个边界 ❌

都不一定,真正的边界, 不是物理结构, 而是”变化约束”

判断是不是好边界的4个标准

1. 变化频率是否一致

   会一起变的, 应该在一个边界里.
   不会一起变的, 应该拆开

   • 用户信息展示
     • 权限规则经常变
     • UI展示变化较少
       放在同一个模块就是坏边界

2. 依赖方向是否单一

   1. 好边界 - 依赖是单向的,不会出现你中有我, 我中有你
   2. 坏边界:

      // user.ts
      import { formatOrder } from '@/order/utils'// order.ts
      import { getUserInfo } from '@/user/service'
      

3. 对外接口是否稳定

   我敢不敢再不通知别人的情况下重构这个模块内部?

   • 敢 → 边界清晰
   • 不敢 → 边界没立住

4. 模块是否能删除?

   如果我现在把这个模块删掉, 除了编译错误, 还有多少地方 “逻辑崩塌”?

   • 好边界 → 能快速定位
   • 坏边界 → 到处报错,到处牵连

feature是最自然的变化单元, 因为需求基本都是 “按业务变”

基础设施不依赖任何业务

应当让UI变为最薄一层.这样视觉变化不会影响业务

完整例子:

没边界的写法:

components/├─ UserCard.tsx├─ OrderList.tsx├─ useUser.ts├─ api.ts

• UI + 业务 + 请求 混在一起
• 改一个地方,全项目震荡

有边界的写法:

features/├─ user/│   ├─ components/│   ├─ useUser.ts│   ├─ service.ts│   └─ index.ts// features/user/index.tsexport { useUser } from './useUser'

只允许从 index.ts 导入

工程化落地

边界不是靠约定, 是靠工具保证

• eslint 限制跨 feature import
• barrel file（统一出口）
• code review checklist

我判断模块边界的核心标准只有一个:
变化是否被限制在边界之内。
如果一个改动需要频繁跨模块联动，
那这个边界一定是有问题的。