目前就在做所谓的"中台",
大致上就像你说的一样.只不过我觉得这种责任分属....
这些各自为政的系统,原本都是各组自己有一套商业逻辑,
他们有很多table和排程去维持系统运作
但是当要把它们拆出来变成"中台"时,
(1)
我要先根据业务单位的需求文件(ex:user看到的前台画面)
去推敲出我需要提供什么样的api给前台串接
(2)
然后跟此后台系统的同仁询问,如果要做这些东西,
我需要哪些table,增删查改大概要怎么做
(同仁只会提供你一个大概,因为这些需求都是新的,
等于是我中台人员需要去了解各系统的业务和排程运作方式,
以及他们各个table是在干嘛的.而且这东西根本不可能讲清楚,
开发时我会看着这些table资料的变化,自己推测他们程式逻辑)
(3)
之后测试以及后续上线时,如果有问题(客人看到数字算错,还是资料查不到)
都是我这边优先来解决(因为给前台串接的api是我写的)
当这类系统越做越多,会发现原组别的loading好像慢慢地都堆到中台身上
而且后续要修改也牵涉到一堆问题,
比如说商业逻辑要调整时,原组别的后台程式要修改,我这边也要配合修改
还是说我这不是"中台",而只是another"后台"而已..?
※ 引述《aoshiken (三十六雨风飘摇)》之铭言：
: 之前在金融业工作过一段时间
: 我也是在金融业才听过"中台"
: 分享一下中台的存在价值
: 首先 银行系统后面很多各自为政的系统 像卡系统 贷款系统 存款系统...etc
: 大部分都只能活在内网 不可以接到外网 而且输出格式五花八门...
: 中台的存在意义 就是在这些系统上面架一层统一的web service
: 让app,网页甚至是外部协作系统可以方便取得对应的资料
: 所以通常中台出来的资料都是统一的json格式
: 但是它们吃到的资料真的是五花八门 有json 有 xml 还有鬼txt之类的东西