拆分服务应基于业务演进节奏与变更影响范围，以限界上下文识别真正独立发布、扩缩容且数据自治的边界；错误拆分将导致“分布式单体”，运维与排查成本激增。
拆分服务不是把单体代码按文件夹切开，而是根据业务演进节奏和变更影响范围，划出真正能独立发布、独立扩缩容、数据不共享的边界——拆得对，一个服务改了，其他九个照常运行；拆错了，就是“分布式单体”，运维成本翻倍，问题排查更难。
用限界上下文识别服务边界，别信“用户/订单/支付”这种默认划分
很多团队一上来就建 user-service、order-service、payment-service，结果发现“创建订单”要同步调用用户校验、库存扣减、优惠券核销、风控拦截……每个环节 SLA 不同、失败策略不同、数据库事务要求不同，硬塞进一个服务里，只会让逻辑越来越重、部署越来越卡。
- 真正该拆的是“能力单元”：比如
coupon-issuance（优惠券发放）走审批流+库存锁，而coupon-redemption（核销）走实时风控+交易上下文，两者连数据库 schema 都不一致，就必须拆成两个服务 - 画出核心流程图，标出每个环节的负责人、超时容忍度、是否允许异步、是否需要强一致性——凡是标着“可最终一致”“部署节奏不同”“失败后走补偿”的环节，就是潜在拆分点
- DDD 不是教条，而是工具：限界上下文不是名词堆砌，而是问一句——“这个功能改了，会影响其他几个服务的测试、发布、监控配置？”答案是“0”，才算边界清晰
proto 契约先行，禁止跨服务直连数据库或共用 DAO 库
服务间通信必须通过明确契约，而不是靠“我们都知道 user 表结构”这种默契。Go 没有接口继承，但 protobuf + gRPC 正好补上这一环：契约即代码，生成即约束。
-
.proto文件必须由服务提供方定义，放在统一目录（如api/order/v1/order.proto），不能散落在各服务internal下 - 禁止在
order-service里直接 importuser-service/internal/repository或拼 SQL 查 user 表——这等于把耦合写死在编译期 - 数据自治不是口号：每个服务的
go.mod里不该出现其他服务的数据库驱动依赖；repository层只对接本服务私有 DB，对外只暴露GetUserByID(ctx, id)这类能力接口 - 示例中常见错误：
conn, err := grpc.Dial("user-service:50051", grpc.WithInsecure()) // ✅ OK // ❌ 错误：db, _ := sql.Open("mysql", "user:pass@tcp(user-db:3306)/user")
内部模块按 handler/service/repository 分层，但用 internal 封装实现细节
单个微服务内部不是“扁平化”，而是要有清晰职责分层，同时防止外部服务越权调用内部逻辑——Go 的 internal 目录是语言级封装机制，不用白不用。
立即学习“go语言免费学习笔记（深入）”；
- 推荐结构：
/cmd/order-service/main.go入口 →/internal/order/handler.go（只做参数解析、响应包装）→/internal/order/service.go（核心逻辑，协调多个 repository 或 client）→/internal/order/repository.go（仅封装本服务 DB 操作） -
handler层绝不处理业务规则，比如“库存不足是否允许下单”这种判断必须下沉到service；repository层绝不返回*sql.Rows或原始 error，只返回领域模型和自定义错误类型 - 所有跨层调用通过 interface 定义，例如：
type UserRepository interface { GetUserByID(ctx context.Context, id string) (*User, error) } // 实现可替换：mock / mysql / redis，不影响 service 层 - 避免把
pkg/common做成“大杂烩”：日志、错误码、中间件可以复用，但“用户校验逻辑”“订单状态机”这类业务敏感代码，必须留在各自服务内
初期别追求一步到位，用“单体先行 + 能力抽离”降低风险
从零开始就建十个服务，90% 会返工。更现实的做法是：先在一个 monorepo 里用清晰目录隔离模块，等某个能力出现明显变更压力（比如优惠券发放上线频率远高于核销），再把它抽成独立服务。
- 先在
/internal/coupon/issuance/和/internal/coupon/redemption/里用 interface 隔离，跑通本地集成测试 - 再把
issuance提炼为独立 module，加go.mod，暴露IssuanceService接口，用 gRPC 对接 - 最后通过
replace github.com/your-org/monorepo => ./services/coupon-issuance在开发阶段联调，上线前才切真实 endpoint - 关键信号不是“代码量多”，而是“每次改它都要拉上三个团队一起回归测试”——这时候，就是该拆的时候了
最容易被忽略的一点：服务拆分不是架构师闭门画图的结果，而是从最近三次线上故障的根因分析里长出来的——哪个环节的修改引发了最多连锁反应，那个环节的边界，大概率还没划准。
