后台是给中台提供技术能力支持的,包括中间件团队,运维团队等。
前台与中台原来是一体的,可以认为我们的业务代码。为了实现业务的管理,拆分出前台与中台,中台更偏向于业务的抽象,公共模版的梳理;前台更偏向与业务的快速落地,利用中台提供的能力快速的实现业务的落地。
如果业务量比较小,几个程序员能掌控整个业务逻辑,就不需要用中台。如果研发有1/3的时间来梳理业务代码的时候,此时说明业务散列程度已经比较高了,此时最好能够梳理出一个模型来,此时敏捷开发的弊端已经体现出来了,如果继续使用敏捷开发,梳理的时间占比将会越来越长。
中台的目的随着业务越来越复杂,就需要一种能力来实现对业务的管理。随着业务越做越多,功能越来越强,应该是越做越简单,而不是越来越难。我们需要对业务这个概念做出抽象,同时实现对业务的管理。
业务抽象业务抽象是一个很复杂的过程,那有没有方法是专门描述业务的,而领域驱动设计是很好的表达业务的一个方法。业务需要边界,而领域具备天然的边界;业务需要内聚,而领域本身就是内聚的;业务有执行流程,而领域服务也具备流程编排的能力;业务需要表达,而通用语言也具备大家都能看的懂的能力。
业务管理业务的横向管理是当前业务具备的能力。
业务的纵向管理是当前业务的执行流程。
在大的业务流程不变的情况下通过通过增加小枝叉的方式来实现对业务的复用。
随着把原有的业务增加到中台,中台的能力将会越来越强大。可以通过中台快速知道业务的范围、执行过程;在业务发生变动时也可以快速知道在那个位置变动;复用原先的流程,在需要变动的位置增加拓展点,来做业务的快速实现。
参考COLA框架 https://github.com/alibaba/COLA.git
如何执行1、基础域建设
参考同行业的实现方案,比如商品域,库存域,订单域,支付域等。
2、通用域建设
此时需要仔细分析当前公司业务,找到核心价值,也就是核心域。比如我们公司是基于电商的租赁模型,则租赁将会成为一个域,而租赁中很重要的一个点是押金计算、押金返还逻辑等,押金也将成为一个域。
3、用例分析
需要拿到变动范围内的全部用例,反推到建设的模型上,模型是不是能过做到领域内内聚,领域之间尽量少的依赖。确定业务的面、线、点,面是领域,线是业务执行流程,点是拓展点。面,线尽量做到不变性,点是抽象部分的实现,具备高度可变性,订单域是一个面,下单流程是一个线,下单过程中的押金计算是一个点,根据租赁类型,组售方式等计算类型不一样,计算结果不一样。
4、确业务身份
流程中走那个人拓展点应该由业务身份确定。阿里基于人、货、场确认业务身份,我们可能要基于人、货、场、租赁来确定业务身份。
5、通用语言建设
明确领域边界,核心概念,能力,业务流程等,并用大家都能看的懂的语言记录下来。
6、通用域编码
根据通用语言实现领域以及流程的编码工作,并把原先定义好的通用语言添加到代码注解中,实现通用语言的自动维护以及业务中台的自动建设。
7、生成单个业务的订单
8、生成多个业务的订单
9、测试与切流
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)