在开始下面的话题之前，我们先看一看有赞原有的核心交易架构。
初步看去，这套架构方案似乎看不出什么问题。事实情况也这样，我们做这套交易方案支持了日百万级的交易规模，取得了很不错的成果。
在2016年，公司经历了飞速的成长， 整体团队人员扩张了数倍， 公司整体业务线从单一的微商城电商交易型态扩张到支持多个垂直行业。交易团队也碰到了很多尴尬的情况：
-
垂直行业接入交易很困难，交易团队对于业务团队的支撑响应速度赶不上业务的迭代速度，最后垂直行业被迫自己完全重做了一套针对垂直业务的交易系统。比如：商业化服务订购，收营，批发等业务。浪费了公司宝贵的技术资源。
-
交易团队的新同学，上手交易核心的开发非常困难，在没有完合弄懂整套系统之间，不敢放手让新同学开发。学习成本极高。
-
很多的玩法不能进行组合，如果想进行组合，必须要求进行重新编码，把组合的方案当做一个新方案来做。比如：虚拟商品的拼团业务， 酒店的分销业务，等等， 都不能用很简单的方案做支持。 产品运营同学的创造性想法，得不到很快的支持。
-
上线了一个小需求，导致的主流的核心交易大面积出现故障。影响范围不能进行隔离。
在此之前，我们先看一看公司对于交易团队的要求，以及业务团队对于交易能力的诉求。
从上图中，可以看到，从业务团队的视角上来看，交易能力，其实是一种云化能力。不管是什么样的业务场景，只要交易场景存在，那么交易能力就应该能覆盖。换句话说，交易团队存在的价值，就是”能够很快速地支持所有业务的交易“。
这个时候稍微清晰了一点当前的困难的原因：原来的我们，一直是在做微商城的业务，认为”微商城的业务规则=交易的能力“。这个定位与垂直业务的期望很不匹配。
既然”微商城的交易规则“不等于”交易能力“，那么交易能力是什么？ 有什么内容？与垂直业务又有什么关系？
这三个是很有意思的问题。 在弄明白这三个问题之前，我们先把我们从一个互联网从业者的角色，转变成一个普通的人。假设我们要去做三件事情，我们看一看现实生活的交易细节：
-
我要去路边摊买一斤瓜子。
“老板，多少钱一斤瓜子” 。“12元一斤奶油的” 。“给我称一斤”。 然后老板给我称了一斤，我付钱， 拿瓜子，走人。
-
我要去楼下吃一碗面。
“老板，热干面多少钱一碗” 。“15元一碗”。“给我来一碗” 。然后我坐下， 吃完面，付钱， 走人。
-
我要去售楼处，买一套期房。
这个场景就更复杂了，我需要先看房周边的环境，看价格，然后弄清楚开发商的承诺， 然后，找售楼小姐聊价格，拿合同，签字， 付现金首付，然后找银行贷款付完余下的钱。 待房子开发完之后，再找开发商确认收房。最后整个交易才算完毕。（PS：如果房子跟原来说的面积不一致，还需要补款。如果差距太大，还要房闹退款等）。
上面例子，都很平常。但是平常的事情，蕴含着几千年的交易规律。我们仔细品味一下上面的细节，发现从大到小的交易，有几个共同的点：
-
交易必须有买卖双方。
-
在初期，买卖双方必须达成一致（如何付钱，如何交货）。达不成一致，就不存在交易。（契约）
-
达到一致之后，买方付钱，卖家交货。PS：可能是先交货，再付钱。也可能是多次付钱。也可能是多次交货。
-
只有买卖双方达不成一致，才存在交易退款维权的情况，包括售后服务。
从理论上来说， 线上系统处理的也是真实世界的问题， 只是手段略有不同。我们再回顾一下自己平常碰到过的交易场景，都逃不出这个范畴。 我们完全有理由把这个结论当成线上交易系统的指导思想。我们对于交易系统的抽象理解就是： 交易的本质是：
买卖双方就付款细节／交货细节／商品质量细节／赔偿细节，先签定一个契约
。而后双方履行契约的全过程。订单仅仅表示双方履约的过程和凭证。
我们看一下新交易的最骨干的模型。
搞明白了我们的核心问题， 那么很多事情就迎刃而解了。
-
快速接入问题：如果我们的交易核心是稳定的，不是给某个业务定制的，那么只要是契约精神可以解决的问题，就应该是交易系统能解决的问题。业务系统只需要做一些适配，就可以无缝接入。接入速度会极大提升。
-
搞定小需求，影响主流交易的问题：这个是原系统在代码组织层面，只要做好隔离，就可以解决的。
-
新人学习成本高的问题： 同理，交易的核心是稳定的，不需要关心太多的业务上的问题，理解成本就会极大的降低。新人接手速度会提升。
-
玩法不能组合的问题：这个问题同样是原设计上的一些缺陷，没有区分横向业务，跟垂直交易。PS：这个会在后面阐述。
要根治交易系统当前碰到的困局，除了重构之外，没有别的捷径可走。
在进行本章节的讲解之前，我们再回顾一下，上面讲的三个生活中的交易场景，我们继续仔细品味一下，三个交易场景的细节点，突然有了一个惊人的发现：
