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