中台建设

　　最近一段时间一直在做前中台的工作，也有一些感想。

　　目前我所接触到的是电商业务，无非是：商品、订单、促销、库存、履约、物流等，今天聊一聊供应链履约。

　　针对供应链而言，属于单后履约环节，大概分为：接单、拆单、定仓、推送订单信息至面单、发票等系统，最后下传至仓，开始物理履约，在此期间可能需要10个系统的几十次交互，系统是为完成用户需求或业务需求而建立的，那么如果在保障业务的前提下，深化领域模型，抽象系统逻辑，建立平台式服务是一个比较大的考验。

　　首先，我们要建立初步的领域模型，以上述履约流程为例，简单的需要调度系统、拆分系统、生产计划系统等，针对调度系统：不需要关心是何种订单（O2O、实体、医药等），更多的关系该订单的调度流程，如：需要【拆分、定仓、发票、面、仓】、【发票、面单、仓】等，根据业务需求将各个系统串联起来，它的最重要的领域即是：系统间交互信息，抓住这一点，抽象系统逻辑，无论是任何类型订单都可以通过调度系统串联起来。

　　其次，拆分系统，主要功能，将用户的订单拆单，拆分维度：商家、商品类型（医药、生鲜、家电等），那么对应的会生成多个订单，也会将原订单金额拆分，如果涉及到优惠（促销、满减、优惠券等），还需要做对应的金额逻辑，那么该系统的最重要的领域即是：拆分维度、促销模式，抓住这一点，抽象系统逻辑，不要关系何种业务接入，而关系该业务的拆分维度、促销模式（分摊金额的比例、优先级等），不断的深耕这个模型。

　　然后，生产计划，主要是根据订单+仓信息+用户地址，选择合适的仓发货或暂停订单等待货源，那么该系统的领域：订单信息、仓信息、送货地址，不关系时何种订单，主要满足系统的领域模型，就可以帮助其定位最合适的发货仓。

　　综上，中台模式是之前工作方式的改变，不能在将业务和领域混为一谈。其实，中台思维就是抛开业务属性，建立系统所对应的领域属性，不断更新和深耕，不断扩大自己的领域范围，但中台决定不能无视业务逻辑，中台不能忘却初心，即：更好、更快的支持业务发展。中台不是纯技术中间件，如：spring等，而是根据错综复杂的业务抽象出来的领域模型，领域模型切记不要有个性化业务字段，而是各个业务抽象出来的字段，对于个性化字段的服务或存储，解决的方式很多，通过扩展字段或扩展逻辑，切记在中台建立的系统中，不能有if(type=‘生鲜’)，这和之前的工作模式无区别。

　　以上，只简单聊了供应链履约的一个小环节，后续逐渐可以聊聊商品、订单、库存的抽象。