架构边界
服务拆分前先观察变化频率、数据所有权和团队协作方式。一个模块如果没有独立的数据语义，只是为了目录整齐而拆出去，往往会增加调用成本。
- 以业务能力定义模块，而不是以技术层级定义模块。
- 跨模块调用需要有明确契约，包括错误码、幂等规则和超时策略。
- 共享代码应保持薄而稳定，避免让公共包成为隐形单体。
接口契约
接口设计的关键是减少误解。字段命名、分页语义、时间格式、错误结构和版本策略都应该写进约定。对外 API 更要保守，因为每一次破坏性变更都会转化为协作成本。
数据与缓存
数据库负责事实，缓存负责速度。缓存失效策略需要与业务一致性要求匹配：商品库存、支付状态、权限信息和内容列表不能套用同一种缓存逻辑。
读多写少适合加缓存，但要注意批量失效。
强一致优先保证事务和状态机清晰。
高并发写需要队列、分片或乐观锁保护。
历史数据适合归档、冷热分离和异步统计。
可观测性
日志、指标和链路追踪应该围绕用户可感知的失败来设计。只记录“程序发生了什么”还不够，也要能回答“哪个用户、哪个请求、哪个依赖导致了影响”。