复杂需求的设计处理--五级之内发展的下线名单的归属

 

复杂需求的设计处理：

 

 

需求---建立程序中对应的模型过程（论证）----开发关键技术（业务可行性）论证---开发

 

 快速反应需求变更，快速编码

 

1，理清原逻辑

2，抛开原逻辑，单独针对变更指定步骤

3，整合原逻辑和新的逻辑--模型论证，技术论证

4，sql,代码参照网上现有的

 

 

 数据库设计的时候，注意冗余关联，三范式拆小表 （高并发的分流）

建立表的时候关联关系，尽可能的冗余

复杂业务逻辑用存储过程实现，高效容易修改

 新增：变化大的字段不必常规建立一个表涵盖所有字段，只要用一个字段存储json即可，用的时候根据类型转化

不用的业务用不同的类，可以在数据库中配置，后台根据数据库配置的类名称实例化即可---配置化

 

（一）需求：理清需求，引导需求，尽可能考虑程序的可维护，易拓展的，稳定性高，性能好的方案

 

 

 

 

1，全量名单基础---不漏邀请关系

2，增量更新补充5级关系（每级过程中更新下进行）

 

 

每个人的名单在扩充，新扩充的只算到5级

 

 

 

 

在上周五，经过讨论后，决定采用产品方提出的数据接口方案，

 

1，第一次调用需求方提供的接口（传入名单时间范围，员工的身份证号\手机号）获取我系统所有用户（本地坐席员工，直通坐席员工，渠道，渠道员工）的直接邀请名单，---第一次调用5次补全到目前为止的5级

(调用的时候之前的层级节点都需要传入，每个人都会拓展)

 

 

2，定时调用需求方组织提供的接口（传入名单时间范围)获取获取每天新增更新的全部有邀请关系的间接邀请名单（每个人新拓展的，可以组成新的5级分支）--继续拓展5级，---仅一级自己另行组合成关联关系

   定时调用需求方组织提供的接口（传入名单时间范围，员工的身份证号\手机号）分别上述四种员工（本地坐席员工，直通坐席员工，渠道，渠道员工）的新增直接邀请名单---继续拓展5级的茎节点

3，基于上述的数据我方组织5级邀请关系（由于第一次拿的只是我系统有的4种坐席的名单，然后在此基础上增量的组织5级要请关系，所以会和全量的名单组织5级关系有点差异）

4，通过接口分配的也同时会放入缓存中做去重

 

 

 

（二）模型过程：

经过过程检验，评审后进行

 

 

直通坐席员工，渠道，渠道员工---只是为了不拨打别人的名单，系统虚占

 

员工通过身份证关联---直通员工（包括本地员工），渠道员工-坐席

分到本地员工的可以直接打---营业部是直销，电销，其他员工都分给直通

 

渠道通过渠道码关联

直接分给相应的渠道或渠道对接人

 

 

这些所有的都需要去重

 

 

 

 

在找到订单的归属之后订单的归属改变之后保存

 

归属

 

坐席

将本地员工，直通坐席，渠道坐席，渠道合在一张坐席表中

 

团队 直通，渠道，

 

本地团队--本地坐席

直通---直通坐席

渠道---渠道坐席---通过渠道码找到的

渠道员工---渠道员工坐席---通过渠道员工身份证关联到的

 

 

程序中关联--

通过身份证的

 

名单表---拉过来存的名单表（另建立表）和员工表关联追溯到所属关系

设置保存bo  1,本地员工，员工表中有冗余所属团中---设置完整bo

            2,其他员工，员工表中有冗余所属团中---设置完整bo

 

 

模型过程总括：

 

 

 

建立虚拟团队，员工

 

 

名单，关联名单入库

 

 

 

用sql找出直接以及5级归属关系

 

设置bo

 

保存及分派

 

设置缓存去重，去重新加入，去重系统目前已有不再分配

 

 

 

 

 

开发关键技术论证：

 

 

sql语句查出归属关系  ---每个名单的归属（统一由邀请码关联）

 

垂直去重----在上面的优先级高，下面的有重复就不查出

 

水平优先级，最近原则

 

 关键技术论证通过后可以开发