领域模型项目实战（二）

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

上节修改了作为初始化校验，本节修改活动创建剩余逻辑。

---

一、app层概览（只放脚本调用逻辑，不放领域业务逻辑）

二、代码说明

1.处理类修改

97行增加实体逻辑，处理activity.config, 来分析一下它属于商家（抽象集合）逻辑还是活动逻辑， 这里我希望根据设置白名单活动的商家去处理改，特定活动做转化处理（spu需要将spu转为sku集合）,在业务继承关系 configitem为顶级父类， ProductActivityConfig为下面子类， 由Traget_PRODUCT OR REDUCE_RULE类去继承ProductActvitiyConfig，逻辑执行符合开闭原则、单一职责等。

2.数据保存

103行 ~ 111行中，存在2个保存，一个是保存活动一个是保存商家活动的配置信息（es）,由app层可以直观的看出保存逻辑，并根据相关业务做事务控制。如果商家数量较多，可以根据item数量做同异步固定线程去执行，可以将需要公用的上下文线程参数在DomainContext中用ThreadLocalMap管理使用。 然后相关线程处理异常问题，统一（CountDownLatch）或线程记录异常然后做处理。

3.领域服务处理

114行， 应该是activityDomainService.postProcessor(activityDomain), 此处逻辑不做修改，分包调整、修改新增删除等独立开来。

---

总结

多人开发中不自觉的就按照面向过程模式开发，逻辑只能顺着往下看，所谓的复用就是在调一遍接口并不在乎接口（类）具体能力。领域业务逻辑分散到app、infrastructure，且逻辑相对混乱，事务控制与业务优化难控制（不清晰）。