erp|干货总结：我对B端系统配置功能设计的思考

导读：在大型B端产品中，不可避免的出现各种配置，配置如同一个个控制阀，决定着业务的走向，并实现saas产品的千人千面，以满足不同客户的诉求，适应不同行业的业务场景。但在随着产品的发展，配置项也越来越多，逐渐变的不可设计与维护。给什么做的配置？配置是如何生效的？好的配置具有什么特点？如何确定配置的维度？针对这些问题，笔者就以自身的工作经验，来给大家说一下如何进行复杂B端系统的配置功能设计。

文章插图
一、给什么在做配置？【 erp|干货总结：我对B端系统配置功能设计的思考】在开始配置之前，我们要想清楚，我们到底在为什么在做配置。
软件系统是现实世界的抽象，在《THINK IN UML》一书中，表述了现实运行的机制：人驱动系统、事体现过程、物记录结果、规则控制运行。由于我们不可能利用一套固定的规则满足所有客户的业务场景，故我们需要支持规则可调整，调整规则的功能，就是配置功能。
我们习惯用用例（use case）的方法来抽象现实世界的需求，一个完整的用例定义由参与者、前置条件、场景、后置条件构成，其中：

参与者通过系统输入物与系统交互，可以是输入的一段指令，一笔订单，一个商品信息等；
前置条件：发生这个用例的前提条件，即输入物满足什么条件才可以发生这个用例
后置条件：发生这个用例之后的结果，会产生哪些影响

那么当我们翻译成UML的语言时，配置就是定义前置条件和后置条件的系统功能。
那么当我们判断输入物满足什么条件时，还是分两类：

当输入物存在时，即满足条件。如：当OMS系统发出打印指令时，即调用配置中指定的打印机进行打印；
当输入物的属性和预设规则满足时，即满足条件。如：当ERP推送商品价格数据到OMS中，由于商品价格数据这一个输入物的所属类别分类属性，满足预设规则1，则自动加价5%；

当我们分析会产生哪些影响时，我们可以分三类：

边界类：影响操作界面是否可查看可操作，或者接口是否可用。权限控制RBAC设计模型和接口的订阅配置，就是典型的对边界类造成影响的配置设计；
实体类：影响数据库表，文档或其他具有持久化特征的数据的格式、内容；如OMS系统设计中的审单功能中，会根据配置在订单上加上赠品商品行；
控制类：影响控制程序，工作流，算法体是否起作用；如OMS系统中，订单会根据配置来决定是否直接跳转到某个状态，如退单长时间未审核，则自动同意的配置

文章插图
在复杂的B端系统中，我们往往发现一个业务无法用一个用例就描述清楚，导致配置设计还是无法进行，如这个业务场景：
ERP将商品资料同步到OMS，OMS加工后，同步至各商城。
由于用例体现了参与者的愿望，用例的执行结果应对参与者来说是可观测和有意义的，那么显然，同步商品资料到各商城，对于业务的起点ERP来说，并不是其愿望，也不可观测，但是不存在没有参与者的用例，用例不应该自动启动。由于参与者可以是非人的，换句话说，参与者可以是用户的一个指令，或者是上游系统的通知，故我们往往将用例根据参与者的不同进行拆分。以笔者参与的OMS产品为例，我们根据长期的实践，习惯根据参与者的不同，划分为三种不同的用例。不同种类的用例，配置一般影响的类别也不一样：

输入用例：比如上游订单系统同步订单至OMS、ERP系统同步商品资料至OMS。配置一般影响边界类；
- 上一页
- 1
- 2
- 3
- 4
- 下一页