架构工作的思考
我接触账务系统有段时间了,直到现在每周都会接到不同业务侧需要提供各种接口,有查询的、有修改的、有统计的。我不是在抱怨我工作量杂多,而是在思考如何提高工作效率,为什么每次业务侧有需求都要集中到账务,还要沟通开会,每个业务新需求评审会都要参加,这样很影响工作效率,我一个个做,就像系统中的单点。
ABC 三个业务方,底下是一个通用的服务。假如你解耦不彻底,你这个通用的服务里有业务侧的代码,这会出现什么问题呢?如果新增业务需求,你会发现很有可能要改代码的是底层的服务,比如说业务 1 来了一个需求,他过来找到你,说我这个需求有个扩展,麻烦你这边升级一下。业务 2 和业务 3 相同,明明有需求的是业务方,为什么修改代码的是我底层呢,业务需求方很多,所有业务需求侧都是你来实现,你是忙不过来的。这时你可能在心中骂“md,明明是业务侧需求,为什么要修改通用服务”,我不是想甩锅(虽然这是公司现在的文化)或者让自己少工作,而是不希望出现单线程的瓶颈,拖慢我们的产品交付速度。
就账务来说,如何做到隔离变化呢?一个交易系统按架构拆分,有用户系统,产品系统,订单系统,支付系统,所谓的账务应该是支付系统,支付就是在交易过程中把购买方的钱付给卖家,支付解决支付与第三方的交互,并记录用户账户的流水。订单是交易的产物,参与交易的主体分为两类:买方,卖方。
账务系统应该把订单业务上浮到各个业务系统中去,只负责交易过程中支付的生命周期,各个业务方自己维护自己的业务的订单信息,在需要支付订单的时候只需要传递用户信息,与金额,冗余商品信息(itemName),支付成功后回调业务修改订单支付状态,业务方需要统计订单的再现支付率,各中订单的类型信息等等,自己就很快完成,不需要写邮件开会,提高的工作效率,降低了沟通成本。
加入新的业务发生了,比如经纪人,他也有交易,也有订单,他在他的模块有订单,只需要调用支付系统,来支付订单即可,他要统计发生的业务数据,不需要账务系统来提供什么接口(Fuck 见鬼去吧,我讨厌开会)。
最后吐槽,我觉得架构的工作,是解耦,隔离变化,把复杂的系统拆分化整为零,变成一棵树,并让树随着业务的发展变化健康长大,而不是变成一个图,互相纠缠,架构不是制定各种规范统一系统,而是隔离各个模块互相的影响,各自玩各自的玩坏了影响也不会扩散,这样开发的也开心,架构也不累。我说这些也许有偏激的地方,但希望能引起大家的思考,希望能向正确的方向前进,加油!