从数据库中心化应用迁移到DDD架构应用的实践难题求解

1. 先复刻数据库的业务逻辑到领域层 #

• 把数据库里所有触发器、存储过程、函数中的业务规则，完整复刻到新的领域层中，让领域模型的逻辑和数据库逻辑完全对齐。这时候适配层的转换器要保证领域对象和数据库实体转换无偏差，应用层调用领域逻辑后回存数据库时，数据库原有的逻辑相当于做双重校验，不会出现冲突。
• 核心是要把数据库里的所有规则（字段校验、状态流转、计算逻辑等）梳理得一清二楚，形成明确的规则文档，再在领域模型里逐一实现，不能有遗漏。

2. 逐步接管业务逻辑的执行权 #

• 等领域层逻辑和数据库完全对齐后，从非核心、低风险的业务场景开始替换：比如简单的查询、基础状态更新，这些场景里先关掉数据库对应的触发器或存储过程，直接用领域层逻辑处理后回存数据库。
• 每个场景替换完成后，必须做充分的回归测试，确保结果和原来完全一致，再推进下一个场景。
• 复杂事务场景可以拆成小块迁移：先把事务里的某个计算逻辑从存储过程移到领域模型，数据库暂时保留冗余逻辑，等整个事务的逻辑都迁移完成，再关闭数据库里的对应部分。

3. 拆解数据库中的耦合逻辑 #

• 数据库里的逻辑往往和数据结构、其他业务逻辑缠在一起，先把通用逻辑（比如金额计算、日期校验）抽成独立的数据库函数，然后在领域层实现对应的方法，逐步把调用方从数据库函数改成领域模型方法。
• 对于触发器里的状态流转逻辑，可以先在领域层实现状态机，应用层调用领域模型的状态转换方法后再更新数据库，同时保留触发器做校验，等确认领域层状态机完全可靠后，再删掉触发器。

4. 重构数据访问层适配富领域模型 #

• 当大部分业务逻辑都迁移到领域层后，重构数据访问层：不再只做简单的实体转换，而是设计基于领域对象的仓储接口，仓储实现层负责把领域对象的状态转成数据库实体并持久化。
• 这时候可以逐步淘汰原来的贫血模型，让应用层直接依赖领域模型，调用其方法完成业务操作。

5. 最终移除数据库冗余逻辑 #

• 等所有业务场景都由领域层处理，且经过足够时间的验证没有问题后，逐步删除数据库里的触发器、存储过程和业务相关函数，彻底完成迁移。

内容的提问来源于stack exchange，提问作者kalidali