基于规则的业务需求设计

        基于规则的业务需求，是在实现特定业务需求时，如考核评分，需求方提供了多种评分规则，需要根据不同的业务场景并依据这些评分规则进行评分的一类业务，业务场景包括：数据报警、考核评分等。

        对于此类业务，需求规则往往是多变的，今天增加一项、明天修改一项，如果被动地根据具体规则进行逐个修改，代码的逻辑判断会越来越多，代码越来越长，最终修改者都可能不知道是要实现什么功能。针对这种场景，我们就需要设计出一种可扩展的规则来减少开发的维护成本，以最少的改动，最快的开发效率来实现新规则，修改旧规则。

        下面我将以考核评分业务为例来说明。

        考核评分主要是对考核主体进行评分，考核主体包括省、市、企业等，每个主体都有自己的实际业务操作，如省市需要做计划，并进行计划审核，企业也需要上报计划，省、市进行审核，评分时会针对上报的及时性、审核的及时性、修改次数、上报是否逾期等指标进行，当然实际业务操作不止计划上报，还有其它的业务操作也会纳入考核范畴。最终需要展示各个主体的总分排名，各考核指标的评分。

        分析业务需求，从输入输出的角度来看，评分的输入包括：评分主体、评分指标及评分规则，输出则是主体评分。输入又可以分两种，一种是变化不频繁的，如评分主体和评分指标；一种是随时间变化而变化的，如评分规则。评分主体有省、市、企业等，每个评分主体有自己的一些属性，如名称、编码等，主体与主体之间也有关系，企业属于省、市，市属于省，先设计每个主体都有两个共同属性：编码、名称。评分指标则是具体的指标，如企业计划上报是否及时、市下属企业的及时率等。评分规则是评分主体和评分指标在具体时间段的匹配，比如设定2023年企业的评分指标有上报及时率、修改次数等指标。最终目的是为了得到评分数据，即每个评分主体在评分时间的得分。由此可得出以下关系表：

         指标实现是指该指标是实现类。在开发时，在这儿指定了指标的实现类，我们可以用反射的方式来调用实现类，如果有两个指标的计算方式一致，则可以使用同一个实现类。如果有新加的指标，现有的实现无法满足，则可以再扩展一种实现方式。如果需要修改一个原有指标，这个指标已被使用，则可以新加一个指标实现，未使用则可以修改原指标。这样，不管是新加还是修改，我们是只是扩展了指标的实现方式，对根据评分规则产生评分数据这个核心业务不是需要做任何修改。

        当然，设计的目的是为了服务于开发，在开发过程中，如何写出易于维护、易于扩展的代码还需要在实践中摸索，只有经过自己真正的实践，对此类型的需求才会有更深刻的理解。