单体架构为何仍是有效起点？
- 单体: 把主要业务能力作为一个部署单元交付，内部调用通常在同一进程内完成;
- 收益: 开发、调试、监控和测试路径较短，使用单库事务也较直接;
- 代价: 代码增长后可能耦合严重，局部修改通常需要整体部署，故障和资源竞争可能影响整个应用;
- 扩展边界: 单体也可以多实例扩展，但难以只扩容其中一个独立业务部分;
模块化单体怎样控制内部复杂度？
- 模块化单体: 保持单一部署单元，同时按业务能力划分有明确接口的内部模块;
- 关键要求: 模块通过约定接口交互，限制对其他模块内部数据和实现的直接访问;
- 收益: 保留本地调用和简单部署，降低无序依赖，为将来有依据的拆分留下边界;
- 限制: 只建立目录却允许任意跨模块访问，仍会退化成紧耦合单体;
微服务如何围绕业务能力独立交付？
- 微服务: 在明确业务上下文内承担聚焦责任的自主服务，拥有自己的实现、部署节奏和数据管理边界;
- 限界上下文: 领域模型具有一致含义的业务范围，服务大小取决于责任而非代码行数;
- 团队自治: 团队能够独立构建、测试、部署与扩容，减少跨团队同步发布;
- 私有数据: 通过服务 API 获取其他领域能力，而不是直接依赖对方数据库表结构;
- 收益: 针对热点独立扩容、隔离部分故障，并允许合理选择不同技术;
- 代价: 网络延迟、分布式事务、跨服务测试、运维费用与可观测性要求显著增加;
如何识别分布式单体？
- 分布式单体: 表面分成多个服务，实际仍必须同步修改、发布或恢复，承担了分布式成本却缺少自治收益;
- 典型信号: 共用表结构、循环同步调用、强制一起升级、一个服务失效拖垮完整请求链;
- 边界判断: 单纯存在服务依赖或低延迟要求不足以证明它是分布式单体，关键是能否独立演进;
- 设计措施: 按业务归属划界，减少共享可变模型，API 向后兼容，调用失败能隔离并有超时;
- 重试要求: 涉及写操作时必须考虑幂等和中间状态，不能要求所有跨服务交互都立即具备全局 ACID;
SOA 与微服务的侧重点有什么不同？
- SOA: 面向服务架构强调通过标准服务接口复用企业能力;
- 微服务: 更强调围绕业务责任的团队自治、独立部署和去中心化数据所有权;
- 重叠: 两者可以共享服务化思想，不应仅凭是否使用某个消息总线判断类别;
什么时候拆成微服务才有价值？
- 判断依据: 共享代码库是否持续阻塞多个团队，业务边界是否成熟，独立扩容与发布是否能带来明确价值;
- 成熟条件: 团队应能处理分布式故障、服务所有权、自动交付和跨服务追踪;
- 演进原则: 先解决当前问题，再拆分已识别瓶颈，不因大型公司的架构外形相似就照搬;