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

处理用例：比如订单打印、订单拆单合单、订单履约、商品价格加价处理。配置一般影响控制类；

输出用例：比如OMS输出订单发货清单至ERP、OMS系统同步商品价格至上游平台。配置一般影响实体类；

我们可以整理出下图：

文章插图
二、配置设计要求上文我们了解了在给什么在做配置，那么一个好的配置应该满足什么条件呢？
第一：配置逻辑自洽
1、根据输入物属性识配自己的规则时，规则之间不能相互冲突；
我们拿商品价格策略配置举例：

文章插图
当我们识别商品的价格属性去适配规则时，我们应使用MECE分析法，按照完全穷尽，相互独立的原则，将属性的枚举值整理出来，当无法完全穷尽时，应设置默认规则；
2、配置与配置之间不能互相冲突；
我们仍拿商品价格策略配置举例：通过识别商品的价格、所属平台、所属门店等属性去适配规则时，可能会出现同一个商品同时满足多个配置的情况；

文章插图
这种情况下，我们需要先判断多个配置是否可以叠加：
可以叠加：当对实体类进行配置设计时，一般策略是可以叠加的。在这种情况下，可以增加配置叠加规则，如设置上限\下限：加价策略都是以输入的原价为基准进行加价，累次加价不能超过原价的8%
不可以叠加：需要增加策略冲突时的应用规则

应用最新的配置：适用最后更新的配置；
指定策略优先级：为配置分配优先级，在配置不可叠加时，选择优先级最高的生效；

第二：配置变更有迹可循：重要的业务配置，需要提供配置变更日志查询，记录配置修改人与修改时间
第三：配置影响的前后数据对应：如果配置影响的是实体类的修改，则应在数据库中记录时，需记录数据原值和配置影响后的数据，不应在同一个字段，用配置影响后的数据直接覆盖原数据。实体类的新增则不需要；
第四：高拓展性：系统的能力建设是持续的，配置的设计可以延续标准的工作流程不断拓展新增；
第五：配置规则可理解：需要提供必要的功能指引，配置规则的入口和操作方式需要符合用户的认知；
第六：不同维度的继承关系清晰：在不同维度设计同一个配置时，需要理清楚是否要继承父辈维度的配置，一般要支持可配置是否要继承继承父辈维度的配置，以免造成修改此维度的配置后，又因为继承了父辈维度的配置，导致修改配置不生效；
三、确定配置管理的维度我们发现，存在配置需要对输入物的多个属性进行识别以决定应用哪个规则的情况，那么我们配置的维度如何设计呢？

文章插图
当我们只有一项配置时，我们当然可以如下设计：
但是如果我们每次新增一个配置，就长出一个新页面，很快就会发现：
用户操作成本高，需要从大量的配置中，找到对应的配置进行操作；
配置设计拓展困难，每次新增配置，就要做一个新的页面；
这时，我们可以查看一下系统的领域模型，找到输入物的共同属性，来组织配置功能的架构：

文章插图
这时我们发现，虽然输入物繁多，业务场景各不相同，但是他们都有一个共同的父类：渠道店铺。如果此时，渠道店铺作为输入物的一个属性，参与配置规则生效的匹配，则可以将渠道店铺这个属性抽离出来，作为配置管理的维度，如：