总计一下系统规则相关的业务逻辑
运行系统规则
一 正向流程
1 查询此系统规则对于的服务组合--》services(目前一个系统规则对应一种服务,建议一直这样使用)
2 查询此系统规则对于的零售商名单
3 对服务和零售商建立订购关系(order_item中skuid就是后台服务id),返回后台服务Id和订购关系(orderItem)的Map=serviceId_OrderItems
(1)同步卖家支付宝信息到汇金
(2) 根据tpId sellerId 后台serviceId,去查询订购关系,如果没有,新增,如果有,则更新(如果有多条,就更新多条,然后随机取第一条)
4 建立后台服务Id和B2B计价模板的映射关系,计算b2c计价模板与b2b计价模板的比例,将映射关系与比例存入Map---》作为参数(bindingMap)
5 生成前台服务==》利用services,和serviceId_OrderItem,
(1) 根据serviceIDList,查询出后台服务(BasicItemDO)
(2) 替换后台服务的地域(不更新后台服务地域,传给前台服务merge使用)
(3) 返回orderItemId与后台服务的Map==》orderItemId_service
(4) 调用sic接口,传入供应商id,零售商id,orderItemId_service,bindingMap,返回零售商对应的所有前台服务
0 遍历orderItemId_service
1 建立orderItemId和对应地域的映射:orderItemId_Area
2 验证补全后台服务的Id和code
3 创建临时的spuId_frontServiceTemp
4 merge frontService
(1)如果有sku,在设置地域,如果sku服务有默认的地域,则使用自己的地域,如果没有,则是使用item的地域
5 根据后台服务merge前台服务===》spuId_frontservice
6 查询买家对应的前台服务,补全信息 ,生成这个买家的spuId_frontService的Map
7 创建一份新的计价模板(B2B计价*Rate的形式),设置到新merge的前台服务中
8 创建一份新的路由 ==》router对应多个rule,一个rule对应一个订购关系,一个订购关系对应一部分地域(不同地域能够路由到一个订购关系),设置到新merge的前台服务中
9 每个rule中都存了一个b2bPriceTemplate和supplierId
10 将新的计价模板id和路由id,设置到merge的前台服务中
11 查询这个卖家的所有前台服务,如果task对应的spu的前台服务有多个,则删除多余的,只保留一个
12 对比spuId_frontService的map,如果之前不包这个服务,直接新建一个前台服务,如果之前存在,则
(1) 删除原有的计价模板
(2) 删除原有的路由规则
(3) 重置商品成交价
(4) 更新前台服务(包括sku服务,地域属性等)
13 返回新增的前台服务,或者更新后的前台服务(一个task对应一个spu的服务,所以理论上返回一个前台服务)
6 新增系统规则
如果之前存在系统规则,则不新增
7 建立前台服务和商品的绑定
(1) 查询卖家的商品(ic搜索,按照指定类目过滤)
(2) 对每个商品进去服务绑定
1 查询这个商品的所有绑定关系
2 如果之前存在这个绑定关系,则先删除旧的绑定关系。然后在新增绑定关系。
8 设置系统规则对应的用户状态
二 反向流程
1 查询task对应的后台服务List
2 查询白名单
3 遍历白名单,删除各种关系
1 遍历白名单
1 删除此task对应的系统规则(卖家在某个spu下的系统规则,有多少,删多少)
2 解除用户商品和服务的绑定关系
(1) 查询用户的商品(ic搜索,按照类目过滤)
(2) 遍历商品List,删除商品在此spu下的对应的绑定关系
(3) 返回成功删除绑定的前台商品id的removeList
3 删除前台服务
(1) 遍历removeList,删除前台服务商品,并删除计价模版和路由规则
4 删除供零间的后台服务订购关系
5 更新用户状态
将添加已执行的用户状态更新为"添加未执行"=1
将删除未执行的用户状态更新为"删除已执行"=8
supplierId:487432435;priceTemplateId:-1
分享到:
相关推荐
业务逻辑设计总结 业务逻辑是指在软件系统中对业务流程和规则的描述和实现。它是软件系统的核心组件,决定了系统的行为和功能。业务逻辑设计是软件开发过程中的一个关键步骤,它涉及到对业务流程和规则的分析、设计...
总结来说,业务逻辑是软件开发的心脏,理解和掌握其概念和实现方式对于构建高效、可维护的系统至关重要。通过深入学习和实践,我们可以更好地理解和运用业务逻辑,避免“丢失”这一核心概念。在实际工作中,不断反思...
- **注意事项**:选择的基础模型应当与当前业务逻辑相匹配,以确保不会与已有的编号产生冲突。 通过上述详细的分析与解决方案介绍,我们不仅能够更深入地理解编号重复问题产生的根本原因,还能够掌握一套行之有效的...
规则引擎的核心功能是将业务逻辑从应用程序代码中分离出来,使得业务规则可以被独立地创建、修改和管理。规则流则是规则引擎中的一个重要概念,它允许开发者以图形化的方式指定规则的执行顺序。 规则流1.1功能介绍...
亿级在线实时动态规则运营系统V2采用分层架构设计,通常包括数据采集层、数据处理层、规则引擎层、业务逻辑层和结果输出层。数据采集层负责从各种数据源收集数据,如日志、API接口等;数据处理层则使用Flink进行实时...
【创建业务逻辑层(BLL)】是软件开发中一种重要的设计模式,主要目的是将应用程序的业务规则和数据访问逻辑分离开来。业务逻辑层作为表示层(用户界面)和数据访问层(DAL)之间的中间层,它处理业务规则的执行和数据...
Drools是一个开源的业务规则管理系统(BRMS),它提供了一套完整的工具链来创建、管理并部署业务规则。Drools支持多种规则语言,包括易于理解的自然语言风格的规则表达方式。 **2. Drools在智能营销中的作用** - *...
规则引擎的使用使业务逻辑与业务规则分离,便于业务规则的集中管理。 2. 规则引擎的好处: 引入规则引擎能够带来多方面的益处,包括: - 实现业务逻辑与业务规则的分离,提高代码的可维护性。 - 动态修改业务规则,...
在IT行业中,ILOG JRules是一款广泛使用的业务规则管理系统(BRMS),它允许开发者通过规则集来定义和执行复杂的业务逻辑。本篇文章将详细探讨如何在Java环境中调用ILOG规则集,主要涵盖两种实现方法。 一、使用...
Drools是Red Hat JBoss BRMS(Business Rules Management System)的一部分,它提供了一种强大的规则引擎,用于处理复杂的业务逻辑。本文将深入探讨drools如何实现动态生成规则文件以及其相关知识点。 一、drools...
总结起来,业务逻辑层是三层架构中的核心,它负责处理业务规则、数据转换、事务管理、错误处理和性能优化等关键任务。理解和熟练掌握BLL的原理和实践,对于开发出高效、稳定、易于维护的软件系统至关重要。
在本项目中,View负责显示和接收用户交互,ViewModel作为View和Model之间的桥梁,处理业务逻辑并更新视图状态,而Model则包含实际的数据和业务规则。MVVM模式使代码更易于测试和维护,同时支持数据绑定和命令,简化...
该系统采用Java的MVC(Model-View-Controller)设计模式,将业务逻辑、数据模型和用户界面分离,提高代码的可维护性和可扩展性。同时,系统可能采用了Spring框架进行依赖注入,以简化组件之间的耦合;Hibernate作为...
业务逻辑代表了应用的核心功能和规则,它独立于用户界面和应用程序的具体实现。在MVC模式中,Model层通常包含数据访问、业务规则和业务服务。例如,`Cart`模型处理购物车的添加、删除和结算等功能。`add()`方法包含...
例如,当用户在表示层提交一个操作,如创建新用户,业务逻辑层会检查输入数据的合法性,处理相关的业务逻辑(如检查用户名是否已存在),并协调数据访问层进行数据存储。这一层确保了业务规则的一致性,提高了代码的...
3. 业务逻辑层(领域层):包含领域逻辑,是业务规则的实现。 4. 共享层:提供通用的服务、工具或数据结构,供多个层使用。 5. 实现层:包含具体的数据库访问、第三方库等,提供接口的实现。 分层架构通常有三个...