本文作者分享了在接手一个单据审批系统后，如何利用领域驱动设计（DDD）进行重构，解决代码不易维护和业务扩展性差的问题。通过重新划分核心域和支撑域，整合业务逻辑到实体和值对象，提取领域事件，提高了系统的可扩展性和降低了耦合度。重构过程中，作者发现并讨论了Java接口使用的一些常见问题，强调接口应发挥多态优势。
用DDD重构会计凭证生成（下）
https://blog.csdn.net/wangleimj88/article/details/120929931?spm=1001.2014.3001.5502
起源
最近接手了一个单据审批系统，该系统由多个微服务构成，其核心功能是单据审批与会计凭证生成。系统核心功能和大致流程如下图所示。
首先员工根据需要创建如采购单或借款单等单据，随后提交给由activiti实现的审批流程，在单据走完审批流程后会根据单据的类型决定是否进行支付。根据单据类型的不同，为单据生成凭证的时机有所区别，有的是审批完毕，有的是支付完毕。接下来就是为审批完毕或支付完毕的单据生成会计凭证。凭证的生成是根据单据类型等属性去DB中找出与其匹配的凭证生成规则，然后按照所匹配的规则生成凭证。最后通过WS接口将凭证发送给财务系统。从本质上看，这个系统终极目的就是生成支付凭证，其余一切功能都是为这个目的而服务的。
为什么重构
接手系统后的第一个需求比较简单，是要根据推送财务系统的结果向系统中配置的相关人员发送邮件。我已经记不清用了多长时间找到的那个推送方法，并在那个调用推送接口后的一个合适的位置添加了一个发送邮件功能。仅仅这一个简单需求的开发和测试的过程就已经让我有了不爽的感觉，简单来说就是代码不易维护和业务扩展性很差。重构的想法也就是在这时萌生的。
上面的需求上线后我大致对系统有了初步的了解，那么接下来就要上难度了。新类型的单据和新支付凭证生成规则的开发。在重构前，新建一个凭证生成规则的步骤如下。
1. 继承一个抽象Builder，将生成凭证所需的数据在新Builder中组织好，这里的组织并不是单纯的拼装数据，重点是要按照一定的业务规则将单据中的数据进行
最低0.47元/天 解锁文章
扫一扫
623
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
