本人菜鸟一枚，做了很多年的活动，想记点感悟，等到多年以后，看着现在写的这些感悟，能回忆一下。
活动做多了，需求越来越多，代码也越来越冗杂，心律交瘁。
为什么呢？有以下特点：
1，活动形式多种多样，
2，奖品类型多种多样
以前在做活动，主要针对商家，为商家提供各种活动能力，主要就三种大类：拉新：想方设法给商家拉来新的用户，比如从外卖客流拉，用户消费特征拉。留存：就是消费中的用户，给用户下一次再来消费的欲望，比如消费满赠券。促活（当时好像内部术语不叫这个名字，意思也一样）：就是消费过的用户，再次给他们做活动，让用户来消费。以这三种大类的形式，衍生出很多小类的活动，比如，外卖赠券，付费券（付3得5元券），阶梯券，精准营销（根据用户的活跃度等给用户发券），餐前、餐中、餐后券；具体更为细节的活动类型就不说了（我也记不清了，老了记忆不好）。这么多活动，一是活动流程不一样，二是券使用方式
现在做活动，针对的主要是用户，之前是针对商家，图的是稳，精准，用户交互环节不多。而且现在已处于直面用户的场景，主要是活跃用户再提高转化，运营就很大胆的想，各种活动形式层出不穷。因为是面对用户，运营想的是，每次我的每次活动都有一点不一样，哪怕是每天一次的签到，运营都会拼命折腾，普通一天签到得奖品，累计签到得奖品，指定日期（特殊日期）签到得奖品，签到还可能是其他操作的前提条件。除了签到，还有抽奖，答题，下载，购买，排行等等。所以活动类型很多，最近一年被折腾的够呛。还有就是奖品，实物，积分，卡券，礼包，红包等等。每种奖品的管理，发放，记录以及后续用户获取的方式都不一样。
吐槽了这么多，问题存在，总得解决。不能为了现在需求ifelse走天下，之前得亏大佬指导了解了DDD这个东西，这个东西我学的不深，才疏学浅。就目前我的理解就是如何识别模型，构建模型，使用模型。
识别模型：这个因人而异，因地而异。因人而异就是每个人看到都不一样，拿我之前做过的交易中的商品价格来说，普通人就看一个售卖价，精明的人看的是单价，促销价，而商家除了上面说到的，还要看进价，因为存储，运输，人工带来的额外成本价。而作为一个程序员，全的看，甚至还看得更多，比如价格分摊（就是促销的时候，每件商品实际的价格，促销分摊了多少钱）。当初也是把我给算昏了，拉着几位同事一起核对才搞定。所以说不同的人看到的模型就是不一样。软件行业也一样，大学毕业学的SSH（struts,spring,hibernate），现在大家常用的SSM(springmvc,spring,mybatis)，最新的spring5的webflux,reactive等。不断的发展，其实他们的本质就是解决构建web服务的问题，不同人看待和解决问题的思维不同，产生的模型不同，从而构建出来的软件也就不同了，效率上就不一样了。因地而异：每一种事物在不同场景下就是不一样的。之前做过权限管理系统，拿人来说，一个人就是普通一个人，基本的特点：名称，身份证号这些。但是一个人在不同的时候就会不同，在家是儿子或者父亲。在公司就是员工，老总，CEO等等。如果简单的定义一个person来容纳这些，肯定是不行的。得加多少的属性字段上去。定义一个角色模型就可以，在环境Context下一个人获得不同的角色进而有不用的操作。
说了这么多，回到如何识别模型的问题上，在我们刚开始开发的时候，其实模型很少，原因就在于我们前期功能少，逻辑简单，很多时候都会简单化的处理问题，KISS（Keep It Simple, Stupid）原则嘛，一个很简单的问题干嘛要复杂化，引入各种组件才支撑，带来程序复杂，项目延期。领导不满意，同事不满意，自己最后也不满意（毕竟钱少了）。最后就只有挥手那啥了。但是到后期，功能越做越多，问题就出现了，更多的IFELSE解决带来大量的代码，再没一点注释和文档，新员工上来就是我去这写的都是啥，改一个地方引发一片问题，新员工都会自我怀疑，新员工的领导也会怀疑这人能力不行，不够细致，办事不够认真！其实里面多少个代码坑怕只有新员工心里知道了。所以这个代码最后就只有老员工能维护（当然他的记忆也得够好才行）。
所以在后期，我们必须引进新的模型。新的模型并不和原来的模型有冲突，许多新的模型的引进其实都是在原来模型之上诞生的。拿活动来说，早期活动奖品为了解决不同类型的奖品，引入type字段，表示奖品的类型。在用户获得这个奖品的时候，然后判断这个类型是什么，再做不同的奖品发放处理逻辑。积分直接发，实物记录一条收货地址等待用户填写，红包、话费同样记录一条账户信息等等。这是我们普遍能想到的前期奖品处理方式。这个方式本身也没错，简单高效嘛。但是问题就出在奖品的本质内容很难去保存，后续奖品处理流程还不一样。实物就是一个名称，这倒还好；红包，你得去记忆红包的金额大小吧，而且红包不可能随便发放，涉及到钱都得财务审批，所以这个红包还得关联财务系统中的红包ID，方便提现。在一个奖品表里面容纳这些就不合适了，当然有人定义出一个extraMap的varchar来存储额外的奖品信息json，这也是很不错的方式，但是这个extraMap定义多长呢？实际应用中又得小心翼翼了。其实我们可以把奖品对应的实际物体给抽离出来，奖品只需要记录这个奖品的内容是（名称，库存，作为奖品展示的图片，发放量等等），奖品信息模型建立的视角就是活动关心的内容，抽离出来的实际奖品，可以为不同类型的物品建立单独的物品库，保存物品的各自独有的信息。卡券的卡号管理，过期管理。红包金额，是否是浮动红包，财务系统中的红包ID等等都可以很详细的记录，不再互相影响。再做的更进一步，可以做一个物品管理系统，管理各种物品，不再跟活动相关联。活动的奖品还可以更加的抽离，奖品在不同活动类型下，奖品的获取方式还不一样。抽奖类：奖品的中奖概率，答题类：答对题目的数目，签到类：累计多少天签到送，哪一天签到送 等等。从这个方面来看，再在奖品的的属性extraMap上做文章，估计又得折磨人了。解决方法还是一样，抽离出奖品获取方式模型。具体实现就不再说了。
识别模型：开发过程中，不仅仅是我们直接能够看到的实际的对象需要建立模型，更多的时候是多对一些流程，操作等也要建立模型。当然建立的时候根据自己的情况而定。SpringMVC为啥会有HandlerMapping，HandlerAdatper等等，其实这也是对一样行为，流程的封装出一个模型，来解决不同的场景问题。
构建模型和使用模型我的感悟较少，就简单说下吧，构建模型：我自身的感悟就是，1，构建模型这个模型除了落地我们的数据库，而且存在我们存在软件代码中，也就是在业务处理的时候其实有些时候，只关心我们模型的一小部分。这也就是抽奖和接口存在的意义。抽奖和接口不仅仅存在我们对外的接口中，也存在我们软件系统里面，常用的就是我们的模板模式中运用。2，模型最好除了基本的字段GETSET方法，也存在一些自我行为操作和状态判断方法，比如判断活动是否活跃，完全没必要拿出活动状态码，开始结束时间进行比较。直接封装到一个isActive方法里面就可以了，简单可靠。构建模型就是你认为这个模型在解决你的问题（场景）的时候应该具备怎样的属性，行为，状态判断。它实际的实现可能依赖别的模型来提供，但是上层来看的时候应该只能看到能看到的，能操作能操作的。还是KISS原则。其实分层也是这样的，业务层，服务层，数据依赖层，每一层都有各自需要解决得问题，模型也就会不一样，所以会有一堆的DTO,BO等O模型
使用模型：其实23种设计模式已经教会了我们如何针对不同的场景采用不同的模式解决问题，创建类，结构类，行为类，基本上在开发过程先认清自己是属于这三种哪一类，再在这里面去寻找适合自己的类型就问题不大了。其实最重要的是自己要有这个思维，想到要去使用一些模式，优化代码。
写在最后，作为一个开发，我也当过菜鸟，我也埋过坑，上面开发过程中不好的事情我也干过。这不是很么可耻的事情（被我坑过的人，不好意思了哦！！！），人嘛，总的做一些不好的，才会去做一些更好的。希望自己可以做更好，勉励自己。骨朵白！
