业务场景与数据库设计冲突场景

最近开发过程中经常会遇到的一个麻烦，虽然对于一次业务的开发来说，业务与数据库可以无脑的通过对象一对一的设计字段。但是在很多业务场景下，产品的初心都是：一次开发，多次使用。所以导致了，在我开发A业务的时候，需要流拓展字段给B业务；再者就是A业务与B业务有关联，需要一次开发设计的数据库承载两个业务的字段...。讨论得出了看起来还行的方案，特开一篇文章用来记录

开发案例

现在有一个商城业务场景有A业务和 B业务： A业务流程节点：B业务流程节点： 可以看出，A业务中，4个子节点就是B业务。 虽然节点流程是一样，但在使用者的逻辑上却是两个完成不相同的。 A业务为商城服务购买，B业务属于购买了服务之后，新增该服务绑定的银行卡。 那么这里就有一个问题了：在设计理念中，两个有相同点的业务应该放在同一业务场景下进行。 即，A业务的所有节点，应该兼容B业务。

好在，本场景中，两个业务联系比较密切。 在2-5节点中，当A业务服务购买时，实际上就是新增当前商城的第一张银行卡，并为商城注册该银行卡服务。 在2-5节点中，当B业务新增银行卡时，实际上就是商城新增一个银行卡成功之后的重复添加操作。 所以在数据库设计字段时，是可以使用一张Pay_Bank 表完美兼容2-5节点的所有信息及状态的。 那么在2-5节点中，所有节点构成应该是： 其中，nodeStatus 节点操作指，本次2-5节点是在进行A业务服务购买还是B业务新增银行卡。 到目前为止，设计上A业务是完美的兼容了B业务。 但是当设计1-2 与 5-6 节点时，A业务就与当前数据库设计发生了比较难调控的冲突。

由于产品需求： 当用户进行服务协议点击下一步后，本商城的服务购买功能节点则更新到第2节点[信息填写]，当进入到第二节点后，用户没有进行下一步操作；则当下一次用户再次打开服务购买界面时，则需要用户直接进入到上次服务购买的最后一节点[当前节点2]，以及回显出当前节点2最后关闭时的所有信息。

需求与设计的冲突

按照上面1-2节点过渡的需求来看，如果是单设计A业务来说，很好实现。只需要设计一张表，表承接当前商城服务购买操作的节点信息即可。 即一张表对应一个商城 表：orgId nodestatus nodeinfo 。 但是由于2-5节点已经需要兼容B业务，服务购买的节点状态及信息已经由pay_bank银行卡负责。 在没有完成节点2，签约信息填写[银行卡信息初始化与保存]，是没有任何数据记录当前商城的服务购买节点及信息的。 总结一下： 由于A业务在流程中需要兼容B业务，所以无法使用一张表去统计A业务的所有信息。

解决方案

既然无法使用一张表，那么可以直接另开一张表，表中记录的是： node org nodeinfo 与A服务前两节点一对一 但是设计出来发现，其实里面的很多字段和pay_bank冗余。 虽然可以在pay_bank中，另开一个字段标识，改变表含义。 但是由于已经存储了2-5节点的信息，所以字段会越来越难维护。 最终解决方案： 最终的敲定解决，既然A服务为 1-2 ，2-5,5-6 。B服务为：2-5. 那么完全可以把2-5拆成一个服务，1-2拆成一个服务，5-6拆成一个服务。 即将本是一个服务业务的场景，拆成三个微服务场景。

总结

以上的总结，是开发到目前为止，最接近去感受到微服务在产品设计上带来的方便观念。 需求在性能上，拆成3个服务是会有所消耗，但是从长远角度上来看。 以后1-2,2-5,5-6，可以分别拆开，去兼容未来的任何一节点。 在我看来，这是对我需求设计提升的一个新高度提升了属于是。