一句话答案

按 DDD 限界上下文拆分，遵循高内聚低耦合、数据自治（每服务独立 DB），避免过早/过细拆分。

核心要点

拆分原则：

1. 业务驱动：按 DDD 限界上下文（订单/用户/商品）
2. 高内聚低耦合：相关功能在一起，减少跨服务调用
3. 数据自治：每个服务拥有自己的数据库
4. 渐进式：先拆核心/变化频繁的模块

反模式： 拆太细(调用链长) / 数据库共享 / 循环依赖

追问与易错

追问方向：

• 拆分后带来什么新问题？
• 什么时候不应该拆分？
• 你们怎么拆分的？

易错点：

• ❌ 微服务越多越好——过度拆分导致调用链长
• ❌ 先拆分再优化——应先优化单体

💡 记忆锚点

拆分口诀"四要四不要"：要按DDD限界上下文拆（订单/用户/商品各自独立）、要高内聚低耦合、要数据自治每服务独立DB、要渐进式先拆核心模块；不要拆太细（调用链变蜘蛛网）、不要共享数据库（耦合回去了）、不要循环依赖、不要没优化单体就急着拆。