微服务设计实例与拆分原则

合并整理设计实例（18 讲）和拆分原则（19 讲）。前半部分用"在线请假考勤系统"串一遍完整设计流程，后半部分是落地时最值钱的原则和避坑清单。

一、完整实例：在线请假考勤系统

需求：员工在线提交请假单，按身份/类型/天数校验，按审批规则逐级审批；请假数据核销后进行考勤统计。

战略设计过程

1. 产品愿景（对齐目标）：为内外部人员提供在线请假 + 自动考勤统计，与只服务内部人员、只能内网用的 HR 系统形成差异。目标清晰的项目这步可跳过。

2. 场景分析（找命令和事件），以请假场景为例：

请假人登录（依赖权限微服务认证）
→ 创建请假单 → 修改请假单 → 提交审批
→ 按审批规则找审批人、分配审批人
→ 审批人逐级审批 → 事件：请假审批已通过
→ 后续动作：通知邮件系统 + 数据发送考勤核销

3. 领域建模（三步收敛）：

• 找对象：请假单、审批意见、审批规则、人员、组织关系、刷卡明细、考勤明细、考勤统计
• 建聚合：聚合根有两个——"请假单"和"人员"。于是有了请假聚合（请假单 + 审批意见 + 审批规则）和人员组织关系聚合（人员 + 组织关系）
• 特殊情况：刷卡明细、考勤明细、考勤统计这三个实体相互独立，找不到聚合根——这是建模时的常见情形。处理方式：它们业务上高度内聚，照样放进一个考勤聚合，只是不设聚合根，聚合内用传统方式管理实体
• 划上下文：请假、人员组织关系、考勤 → 三个限界上下文，映射微服务

这个例子最有价值的点就是"考勤聚合"——不是所有业务都是富领域模型，DDD 的框架照用，个别原则灵活变通。

二、单体向微服务演进的三种策略

策略	做法	类比	适用
绞杀者	单体之外新建微服务，逐步剥离替代，慢慢"绞死"单体	建筑拆迁：先建新楼再拆旧楼	大多数遗留系统改造
修缮者	整体不动，只把有问题的部分（高性能要求、烂代码、发版频率不一致）剥出来独立	古建筑修复：外观不变内里翻新	局部优化
另起炉灶	推倒重建，旧系统照跑，新系统并行建设后切换	拆了重盖	大型核心系统不建议——重构不稳定性 + 未知技术风险 + 团队磨合，风险叠加

三、不同场景的建模策略

• 新建简单系统：一个领域就是一个小子域，直接事件风暴
• 新建复杂系统：三步走——先按流程/功能边界逐级拆子域分别建模 → 再跨子域微调（重点是聚合重组）→ 最后按拆分原则设计微服务
• 遗留系统局部改造：把要剥离的功能当一个简单子域来建模，注意新老系统兼容，必要时加防腐层

四、DDD 四大使用误区

1. 所有领域都上 DDD ——DDD 成本不低，资源有限就聚焦核心域，从富领域模型的业务开始，别全面铺开
2. 全部套战术设计 ——聚合根+仓储擅长管"新建和修改"的一致性（比如订单总额和明细一致），但不擅长大数据量查询；统计分析这类贫领域模型业务，一条 SQL 能解决的事别硬套 DDD
3. 重战术轻战略 ——领域模型是微服务设计的输入，边界划不清，代码写得再规范也白搭。战略设计更重要
4. 认为 DDD 只能用于微服务 ——DDD 比微服务早十年，单体一样能用

一句话总结：把 DDD 当工具，不要让它束缚思想，切勿为了 DDD 而 DDD。

五、微服务设计四原则

1. 领域驱动，不是数据驱动，也不是界面驱动——先建模再拆分，不是先设计库表，更不是前端要什么就改核心逻辑
2. 要边界清晰的微服务，不是泥球小单体——聚合之间杜绝领域服务互调和数据表依赖，靠应用服务编排或事件驱动解耦
3. 要职能清晰的分层，不是什么都放的大箩筐——应用层管编排、领域层管核心逻辑，可复用能力持续向下沉淀
4. 要能 hold 住的微服务，不是过度拆分的微服务——没有 DevOps/自动化监控能力就别拆太细；逻辑边界划好了，哪怕先做单体，将来随时能拆

第 4 条特别值得记住：拆不拆是能力问题，能不能拆是设计问题。设计到位了，拆分只是时机选择。

六、拆分要考虑的六个因素

领域模型是主要依据，但不是唯一依据：

因素	说明
领域模型	按职责单一、功能完整拆分（基础）
需求变更频率	敏态和稳态业务分离，高频变更别拖累稳定功能
性能	高性能压力的功能独立出去，避免拖累整体
组织架构	拆分尽量别打破团队边界（康威定律），单服务团队 10~12 人为宜
安全边界	特殊安全要求的功能独立
技术异构	同一业务域内 Java/.NET/大数据混杂时按技术边界拆