前台,中台,与后台
后台是给中台提供技术能力支持的,包括中间件团队,运维团队等。
前台与中台原来是一体的,可以认为我们的业务代码。为了实现业务的管理,拆分出前台与中台,中台更偏向于业务的抽象,公共模版的梳理;前台更偏向与业务的快速落地,利用中台提供的能力快速的实现业务的落地。
何时需要中台
如果业务量比较小,几个程序员能掌控整个业务逻辑,就不需要用中台。如果研发有1/3的时间来梳理业务代码的时候,此时说明业务散列程度已经比较高了,此时最好能够梳理出一个模型来,此时敏捷开发的弊端已经体现出来了,如果继续使用敏捷开发,梳理的时间占比将会越来越长。
中台的目的
随着业务越来越复杂,就需要一种能力来实现对业务的管理。随着业务越做越多,功能越来越强,应该是越做越简单,而不是越来越难。我们需要对业务这个概念做出抽象,同时实现对业务的管理。
业务抽象
业务抽象是一个很复杂的过程,那有没有方法是专门描述业务的,而领域驱动设计是很好的表达业务的一个方法。业务需要边界,而领域具备天然的边界;业务需要内聚,而领域本身就是内聚的;业务有执行流程,而领域服务也具备流程编排的能力;业务需要表达,而通用语言也具备大家都能看的懂的能力。
业务管理
业务的横向管理是当前业务具备的能力。
价格域_(订单域)_计算商品押金_calucateCommodityDepositPrice
价格域_(订单域)_计算商品租金_calucateCommodityRentPrice
优惠域_(租金域)_计算折扣金额_calucateDiscountAmount
租金域_(价格域)_计算单个商品首月支付金额_calucateFirstPayMonths
租金域_(价格域)_获取租金配置信息_getRentMappingMonth
押金域_(价格域)_计算押金_calucateDeposit
价格域_(订单域)_计算商品维度价格_calucateItemPrice
价格域_(订单域)_计算母单纬度订单价格_calucateOrderPrice
订单域_()_订单价格试算_tryToCalucateOrderPrice
优惠域_(租金域)_构建优惠域_getCoupon
租金域_(价格域)_构建租金域_buildRentInfo
押金域_(价格域)_构建押金域_calucateDeposit
订单域(Order)订单价格试算:tryToCalucateOrderPrice价格域(OrderPrice)计算母单纬度订单价格:calucateOrderPrice计算商品维度价格:calucateItemPrice计算商品租金:calucateCommodityRentPrice计算商品押金:calucateCommodityDepositPrice租金域(RentInfo)计算单个商品首月支付金额:calucateFirstPayMonths获取租金配置信息:getRentMappingMonth构建租金域:buildRentInfo优惠域(Coupon)计算折扣金额:calucateDiscountAmount构建优惠域:getCoupon押金域(Deposit)计算押金:calucateDeposit构建押金域:calucateDeposit
租前流程_()_计算订单价格_calucateOrderPrice
租前流程()计算订单价格:calucateOrderPrice
业务的纵向管理是当前业务的执行流程。
业务复用
在大的业务流程不变的情况下通过通过增加小枝叉的方式来实现对业务的复用。
随着把原有的业务增加到中台,中台的能力将会越来越强大。可以通过中台快速知道业务的范围、执行过程;在业务发生变动时也可以快速知道在那个位置变动;复用原先的流程,在需要变动的位置增加拓展点,来做业务的快速实现。
中台的实现方案
技术实现
参考COLA框架 https://github.com/alibaba/COLA.git
如何执行
1、基础域建设
参考同行业的实现方案,比如商品域,库存域,订单域,支付域等。
2、通用域建设
此时需要仔细分析当前公司业务,找到核心价值,也就是核心域。比如我们公司是基于电商的租赁模型,则租赁将会成为一个域,而租赁中很重要的一个点是押金计算、押金返还逻辑等,押金也将成为一个域。
3、用例分析
需要拿到变动范围内的全部用例,反推到建设的模型上,模型是不是能过做到领域内内聚,领域之间尽量少的依赖。确定业务的面、线、点,面是领域,线是业务执行流程,点是拓展点。面,线尽量做到不变性,点是抽象部分的实现,具备高度可变性,订单域是一个面,下单流程是一个线,下单过程中的押金计算是一个点,根据租赁类型,组售方式等计算类型不一样,计算结果不一样。
4、确业务身份
流程中走那个人拓展点应该由业务身份确定。阿里基于人、货、场确认业务身份,我们可能要基于人、货、场、租赁来确定业务身份。
5、通用语言建设
明确领域边界,核心概念,能力,业务流程等,并用大家都能看的懂的语言记录下来。
6、通用域编码
根据通用语言实现领域以及流程的编码工作,并把原先定义好的通用语言添加到代码注解中,实现通用语言的自动维护以及业务中台的自动建设。
7、生成单个业务的订单
8、生成多个业务的订单
9、测试与切流
为何必须要做业务管理
业务增长的管控
随着业务飞速发展,业务复杂度飞速提高,而代码是个散列的过程,随着代码量的增大,离散度会越来越高,代码再掺杂算法,这个过程只有程序员能看懂。而通过领域通用语言的管理,代码越多,会越丰富。
自动生成的业务大图
整个业务大图的生产过程随业务增而增,随业务减而减少。
高效的业务逻辑查询工具
业务管理分为横线管理与纵向管理,既能看到全貌,也可看到细节。
产研的高度统一
基于点,线,面的模式,大家都非常清晰。随着业务增产,哪条线需要变动,那个点需要增加,大家都很统一。减少了从产品的心智模型到开发的数据模型的沟通问题。