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

1. TOC(Technical-Oriented Consideration)

  • 技术导向的考量:关注技术实现细节、性能和稳定性,通常涉及底层技术选型、接口调用、容错处理等。

  • 典型问题(如你提到的例子):

    • RPC 调用:同步/异步、超时时间设置(结合链路耗时)、错误率监控、熔断降级策略。
    • 故障处理:服务宕机时的兜底逻辑(如重试、缓存降级、默认返回值)。
    • 可观测性:接口耗时、错误率监控、日志追踪(快速定位 CPU/内存异常)。
    • 上线后验证:调用量是否符合预期,是否需要限流或扩容。
  • 核心目标 :确保技术方案的可靠性可维护性


2. TOB(Business-Oriented Consideration)

  • 业务导向的考量:关注业务逻辑的设计合理性、数据一致性、用户体验等。

  • 典型问题

    • 设计合理性:为什么选择当前方案(如订单状态机设计、支付流程)。
    • 数据一致性:如何保证分布式事务(如最终一致性 vs 强一致性)。
    • 业务兜底:异常场景下的补偿机制(如库存超卖后的退款流程)。
  • 核心目标 :满足业务需求,同时保证数据正确性流程闭环


3. 两者的区别与联系

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

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

  • TOC 侧

    plaintext 复制代码
    1. 技术选型:为什么用 RPC(如性能需求)?同步/异步的权衡?
    2. 容错设计:超时时间(如 200ms,因链路总耗时需<1s)、熔断阈值(如错误率>5%触发)。
    3. 监控:埋点耗时/错误率,通过日志+Metrics+Trace 快速定位问题。
    4. 兜底:缓存旧数据、默认返回值、异步重试队列。
  • TOB 侧

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

5. 总结

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

https://github.com/0voice

相关推荐
对着晚风做鬼脸21 小时前
MySQL进阶知识点(六)---- 存储引擎
数据库·mysql
JiKun21 小时前
ECMA 2024(ES15) 新特性
前端·javascript
百锦再21 小时前
从 .NET 到 Java 的转型指南:详细学习路线与实践建议
android·java·前端·数据库·学习·.net·数据库架构
i小杨21 小时前
前端埋点(打点)方案
前端·状态模式
卷Java21 小时前
uni-app 模板语法修复说明
java·数据库·spring boot·uni-app·mybatis
前端加油站21 小时前
时间转换那些事
前端·javascript
风清云淡_A1 天前
【VUECLI】node.js打造自己的前端cli脚手架工具
前端·node.js
没有bug.的程序员1 天前
MySQL 在金融系统中的应用:强一致性与高可用架构实战
java·mysql·金融·架构·高可用·强一致性
我要用代码向我喜欢的女孩表白1 天前
HBase全量+增量迁移import/export方式
大数据·数据库·hbase
YuspTLstar1 天前
一文掌握Redux-toolkit核心原理
前端·react.js