新需求开发-重构老的逻辑

最近在做一个需求，把客户迁移从一个地方迁移到另外一个地方。之前有过类似的需求，我参考之前的实现逻辑，实现这次需求。不了解之前的需求，不敢在之前的实现上重构，增量重构

主要步骤有一个待迁移的客户列表，在数据库表中。迁移步骤

1.根据多个规则过滤用户，命中规则的用户不迁移

2.发送短信,IM等通知客户

3.校验通知结果

4.执行迁移

参考之前同事写的代码，发现和自己的习惯有些不太一样的地方。

1. 代码基本没有注释，不太好阅读

2.部分代码有缩写，加上没有注释，要联系上下文，才能理解

3.部分入参、出参是map类型。不知道map里面放的是什么，需要看上下文

4.部分基础、工具服务和业务逻辑耦合在一起，不能复用。比如，发送通知，应该是一个可以复用的实现。调用外部接口，发送通知。接口可以直接定义为，sendMsg(targetUser, msgContent)。代码和业务耦合了，不能复用，入参是业务实体，在内部拼接消息内容等。应该把拼接消息的逻辑放到应用层，或者converter里面。消息发送完成后，

5.做了记录操作的动作，把操作保存到数据库。保存内容应该跟业务无关的，把业务相关的放到操作内容里面，不应该单独建一列，这样，其他场景就不能复用了。因为其他场景，可能没有这一列

6.没有按照公司的四层架构实现，在领域层创建了一个发送消息的领域服务。根据公司的规范，应该在domain创建一个support接口，基础设施层实现发送消息逻辑。在应用层，拼接好消息内容，调用domain层的接口发送即可。问了下大模型，领域服务应该是在实体不能沉淀，跨领域对象的逻辑，定义领域服务。公司不推荐创建领域服务，推荐把业务逻辑沉淀到领域对象。应用层实现业务编排

也有写的好的地方，值得学习的地方

1.批处理，提高系统性能

2.查询、更新数据库，使用了一个大的类型，这样不用每个字段更新都写一个方法

3.大部分实现是符合公司四层架构的

4.日志打印的比较多，好定位问题