【软件工程】tob和toc含义理解

{⌐■_■}

于 2025-07-09 18:54:11 发布

阅读量760

点赞数 5

CC 4.0 BY-SA版权

文章标签：软件工程 tidb mysql 数据库 golang 前端

本文链接：https://blog.csdn.net/m0_74282926/article/details/149231252

1. TOC（Technical-Oriented Consideration）

技术导向的考量：关注技术实现细节、性能和稳定性，通常涉及底层技术选型、接口调用、容错处理等。
典型问题（如你提到的例子）：
- RPC 调用：同步/异步、超时时间设置（结合链路耗时）、错误率监控、熔断降级策略。
- 故障处理：服务宕机时的兜底逻辑（如重试、缓存降级、默认返回值）。
- 可观测性：接口耗时、错误率监控、日志追踪（快速定位 CPU/内存异常）。
- 上线后验证：调用量是否符合预期，是否需要限流或扩容。
核心目标：确保技术方案的可靠性和可维护性。

2. TOB（Business-Oriented Consideration）

业务导向的考量：关注业务逻辑的设计合理性、数据一致性、用户体验等。
典型问题：
- 设计合理性：为什么选择当前方案（如订单状态机设计、支付流程）。
- 数据一致性：如何保证分布式事务（如最终一致性 vs 强一致性）。
- 业务兜底：异常场景下的补偿机制（如库存超卖后的退款流程）。
核心目标：满足业务需求，同时保证数据正确性和流程闭环。

3. 两者的区别与联系

维度	TOC	TOB
关注点	技术实现细节（How）	业务逻辑设计（Why）
典型问题	性能、容错、监控	数据一致性、用户体验、流程设计
案例	RPC 超时设置、熔断配置	订单状态机设计、分布式事务方案
产出价值	系统稳定、高效	业务合理、闭环

4. 如何回答这类问题（面试或方案评审）

TOC 侧：

1. 技术选型：为什么用 RPC（如性能需求）？同步/异步的权衡？
2. 容错设计：超时时间（如 200ms，因链路总耗时需＜1s）、熔断阈值（如错误率＞5%触发）。
3. 监控：埋点耗时/错误率，通过日志+Metrics+Trace 快速定位问题。
4. 兜底：缓存旧数据、默认返回值、异步重试队列。

TOB 侧：

1. 业务设计：为什么需要这个接口（如订单创建必须校验库存）？
2. 数据一致性：如何保证（如通过消息队列+定时任务补偿）。
3. 异常场景：用户支付失败后，如何引导重试或自动取消订单？

5. 总结

TOC 是技术深度，TOB 是业务广度，两者结合才能体现全局思维。
即使代码是 CRUD，能说清技术权衡（TOC）和业务价值（TOB），就是高质量产出。

https://github.com/0voice