交易系统的软件工程设计模式

金融软件出错的代价很高：重复下单、余额不一致、悄无声息的部分失败。设计模式不是用来摆设的奖杯——它们是针对反复出现的失败模式的应对方案：用事件溯源实现可审计性，用 CQRS 让读取与写入分别独立扩展，用熔断器阻止连锁宕机，用幂等性确保重试不会造成重复交易。

撮合引擎、风险检查和行情发布器之间不应在一团乱麻里互相直接调用。一条发布/订阅总线让撮合引擎只管发出成交，下游服务可以订阅，而无需了解上游的实现细节——但你仍然必须选择投递保证（至少一次 vs 恰好一次）以及供重放使用的保留策略。

熔断器在反复失败后停止调用一个生病的依赖，给它恢复的时间，同时保护你的线程池。隔板隔离资源池，使一个失控的分析任务无法把下单提交饿死。

订单和转账有合法的生命周期。把允许的状态转移编码进有限状态机，让非法跳转无法发生。再为客户端请求配上幂等键，这样网络重试就不会创建出重复的有效订单。

中心化交易场所按价格-时间优先，把新进订单与挂在簿上的流动性撮合。链上撮合器（如许多 Layer 1（一层 / 主链）DEX 的设计）必须是确定性的：每个验证者重新执行同一序列，并到达完全相同的状态——GaiaEx 从 Hyperliquid 的规则中继承了这一模型。

不要在第一天就盲目照搬每一个模式。先从清晰的边界、结构化日志，以及围绕资金流动的测试做起。当对账的痛苦出现时再加上事件日志；当外部 API 不稳定时再加上熔断器。模式解决的是真实的擦伤，而不是想象出来的伤。