早期做面向消费者的互联网系统时，我最容易感知的技术挑战来自数据量和并发。
一次活动会带来多少流量，缓存能否承受，数据库查询是否足够快，消息是否会堆积。这些问题不一定容易解决，但衡量方式相对直接：耗时、吞吐、错误率和资源使用都能提供反馈。
后来参与企业软件建设，我遇到了另一种复杂度。
系统的访问量没有那么极端，业务模型却明显更难保持清楚。
更多角色意味着更多视角
面向普通消费者的产品，用户身份通常相对统一。企业软件则可能同时服务公司管理者、项目负责人、一线操作人员、财务和外部合作方。
他们面对的是同一批业务数据，能够执行的操作和关心的信息却完全不同。一个状态对操作人员意味着下一步任务，对管理者可能只是统计口径，对财务又关系到能否结算。
权限因此不只是判断“能不能访问”。它会与组织层级、数据范围、业务阶段和具体角色结合。组织调整以后，原有权限模型也可能随之变化。
当角色没有定义清楚时，代码里便会出现越来越多针对身份和场景的条件判断。
流程并不总是标准的
企业之间的工作方式存在差异。即使处理相似业务，不同公司也可能使用不同字段、审核节点和责任划分。
产品希望建立标准流程，客户则希望系统适应已经运行多年的习惯。两种诉求都合理，系统只能在标准化与定制化之间选择位置。
流程配置、动态表单和规则引擎能够提供灵活性，也会让一次操作的实际路径取决于当时配置。问题排查不再只是重放请求，还要还原用户身份、组织关系、业务状态和配置版本。
低流量不等于低风险
ToB 系统的用户数量可能有限，单次操作的重要性却更高。
一笔数据可能参与后续对账和结算，一个错误状态可能阻断整条业务流程。很多操作还跨越较长时间，今天录入的信息要在数周以后继续使用。
这类系统对数据正确性、状态完整性和变更可追踪性的要求，并不比高并发系统低。只用接口耗时和机器负载评价稳定性，很容易忽略业务上的失败。
技术需要先建立业务模型
做 ToC 系统时，我习惯先关注容量和性能。转向 ToB 以后，越来越多时间用在概念和边界上。
一个业务对象在不同阶段叫什么，哪些变化可以撤销，谁有权触发，外部系统失败后本系统处于什么状态。这些问题如果没有在设计阶段说明，最终都会以代码分支的形式出现。
业务抽象不是把现实压缩成几个漂亮的类，而是尽可能找到在变化中仍然稳定的关系。哪些属于核心模型，哪些只是展示差异，哪些必须保留为客户配置，需要产品与技术共同判断。
两种复杂度并没有高下之分
ToC 和 ToB 并不是两套完全对立的技术。企业系统同样会遇到性能问题，消费者产品也有复杂流程。
真正的变化是，过去我容易把系统复杂度等同于流量规模，后来才意识到，复杂度也可能来自角色数量、规则差异、时间跨度和组织边界。
看见复杂度来自哪里，才知道应该把设计精力放在哪里。