B2B平台的数据模型远比C端复杂。一个企业用户可能对应多个采购员、多个收货地址、多套审批流程，这些都要在底层设计时就考虑进去。我参与过的一个项目，初期把用户表设计成简单的“企业-个人”两级结构，结果上线后才发现，一个大型采购商旗下有十几个子部门，每个部门还有独立的预算和权限，这种结构根本没法扩展。
真正合理的做法是把企业组织架构、角色权限、采购规则都抽象成独立模块。比如企业表、部门表、岗位表、人员表分开设计，通过关联关系实现灵活配置。这样一来，同一个企业可以定义采购员、审批员、财务员不同角色，每个角色看到的数据和操作权限都不一样。
商品数据这块也有讲究。B2B商品通常有多个规格、多种价格策略，比如阶梯价、协议价、促销价，这些价格规则需要在数据模型层面处理好。我见过一个平台把价格直接硬编码在商品表里，改个价格要动整个数据库，简直是一场噩梦。正确的做法是把价格策略抽象成独立规则引擎，支持灵活配置。
企业采购跟个人买东西完全是两码事。个人用户看中商品直接下单付款就完事了，但企业采购往往需要询价、比价、议价、审批、签合同这些环节。平台架构必须支持这种复杂的交易流程，而不是简单粗暴地“加购物车-下单-支付”。
我观察到一个很有意思的现象：很多B2B平台把交易流程设计成跟淘宝一样，结果企业用户根本不买账。因为他们需要的是“询价单-报价单-订单”这种专业流程。比如一个工厂要采购一批原材料，先发询价单给几个供应商，等收到报价后比价，选中一家再下单，这个过程可能需要好几天。平台如果不能让用户走完这个流程，那功能就是摆设。
订单管理这块更要精细化。企业采购经常出现分批收货、部分退货、账期结算这些情况，订单状态机必须设计得足够灵活。比如一个订单可以拆成多个发货批次，每个批次独立确认收货、独立结算，这种功能在C端电商里几乎用不到，但在B2B平台里是刚需。
B2B平台的支付体系跟C端完全不是一个量级。个人支付无非就是微信、支付宝、银行卡，但企业支付涉及对公转账、承兑汇票、信用证、账期支付等多种方式。平台架构必须设计一个统一的支付网关，能够对接各种第三方支付渠道和银行接口。
我见过最头疼的是账期管理。很多B2B交易都是先发货后付款，比如给采购商30天账期。这就要求平台有完善的信用评估体系、账期控制逻辑、逾期催收机制。有一次我们对接一个大型采购商，对方要求用“电子商业承兑汇票”支付，光对接这个支付方式就折腾了两周，因为汇票的验真、背书、到期兑付这些流程太复杂了。
结算这块更考验架构能力。B2B平台通常涉及多级结算：买家付款到平台，平台扣除佣金后再结算给供应商。有时候还有分销商介入，结算链路就更复杂了。我建议采用“分账系统”的设计思路，每一笔交易进来，系统自动按照预设规则分配资金，再分别结算给相关方，避免人工对账的麻烦。
B2B平台一旦跑起来，业务增长往往超出预期。我见过一个平台上线半年后，日均订单量从100单涨到5000单，原来的单库架构直接扛不住，不得不紧急停机扩容。
这种教训告诉我们，架构设计时必须考虑水平扩展能力，数据库、缓存、消息队列这些基础设施都要支持弹性伸缩。
微服务架构在B2B平台里特别适用。因为业务模块之间解耦得很清楚，比如用户服务、商品服务、订单服务、支付服务可以独立部署、独立扩展。有一次我们做促销活动，瞬间流量暴涨，但只要把订单服务加几个节点就能扛住，其他服务完全不受影响。要是用单体架构，这种场景根本没法玩。
接口设计也要留足余地。B2B平台经常需要跟企业内部ERP、WMS、CRM系统对接，这些接口标准五花八门。我建议采用API网关统一管理，对外暴露标准接口，内部各服务之间通过消息队列异步通信。这样就算对接方系统再烂，也不会拖垮平台核心服务。说实话，对接企业系统这事儿，什么奇葩情况都有可能遇到，架构设计必须防着点。
