是不是把简单问题复杂化了

[streetlight8023]

核心代码是这块吧
IActivityDTOParser activityDTOParser = commonFactory.getActivityDTOParser(contextParam.getFunctionCode(), contextParam.getActivityType()); BaseActivityPartDTO activityDTO = (BaseActivityPartDTO) activityDTOParser.buildDTO(contextParam.getRequest()); contextParam.setActivityDTO(activityDTO); doRuleCheck((BaseActivityPartRequest) contextParam.getRequest(), activityDTO.getRules()); doAction(contextParam);
所有活动的公共部分就是 规则校验，（活动时间,有效性。。。）具体内部还是要自己写doAction。感觉并没有降低太多的开发成本

[caisl]

streetlight8023你好，你的这个问题，让我重新思考了下做这个项目到底是为了解决什么问题，框架的存在主要是为了简化开发成本制定规范提升效率，在实际的业务场景里面我有使用这个框架去接入多种不同类型的营销活动，也在团队内部推行过，整体模型抽象上还是比较易懂的，让开发可以更加专注于业务的开发，规则和对应的动作在不同的营销活动中都是存在类似的，所以设计之初是为了复用相同的rule和action，在doAction里面实现调用各个组件去完成奖励通知等等动作，当然目前这个版本离我想要还是有一定的距离，日后有时间也会进行优化

[william-tu]

我觉得把常用rule组件和action组件写好 然后做成可配置化页面 提供给运营会解决大量活动开发需求 参考活动盒子

[william-tu]

但活动需求变化太大也是个问题 复杂的需求还得手写

[codexiaojun]

streetlight8023你好，你的这个问题，让我重新思考了下做这个项目到底是为了解决什么问题，框架的存在主要是为了简化开发成本制定规范提升效率，在实际的业务场景里面我有使用这个框架去接入多种不同类型的营销活动，也在团队内部推行过，整体模型抽象上还是比较易懂的，让开发可以更加专注于业务的开发，规则和对应的动作在不同的营销活动中都是存在类似的，所以设计之初是为了复用相同的rule和action，在doAction里面实现调用各个组件去完成奖励通知等等动作，当然目前这个版本离我想要还是有一定的距离，日后有时间也会进行优化

不更了嘛