当然 ， 保留凭证服务也不是不可以 ， 不过需要将门面服务中负责组织单据数据的代码全部迁移到凭证服务中 ， 门面服务仅需要发送单据标识给凭证服务 ， 然后由凭证服务自己根据单据标识去获取单据然后为其生成凭证 ， 这个折中的方案对于创建新的凭证生成规则的优点是不用同时修改两个微服务的代码 ， 至少提升了服务的内聚性 。
结语
至此大致的重构基本介绍完毕 ， 不过还有很多细节并未说明 ， 比如用约定优于配置原则将单据类型与其不同的明细在一个配置类中对应起来 ， 比如在规则代码化时 ， 用类针对不同类型单据定义其规则的“凭证摘要说明”等等 ， 这些都是经过多轮重构后权衡利弊最终选择的设计方案 。
经过上述重构 ， 再添加一个新的凭证生成规则要做的就是在lder的那些实现类中找到相应的类 ， 加上一个单据规格的定义 ， 然后将该类的.class文件上传到Git即可 。因为这是系统的核心功能 ， 为了保证万无一失 ， 重构后的代码与原代码一起部署 ， 重构代码生成的凭证保存到单独表中 ， 并通过程序与原代码生成的凭证进行自动比对 。
【领域驱动设计用DDD重构会计凭证生成（下）】想用好DDD ， 除了“学”之外 ， 更重要的是“习” 。路漫漫其修远兮 ， 逆水行舟不进则退 ， 锻炼好自己 ， 把内卷进行到底 。

• Android设计模式之代理模式 Proxy
• 代理 proxy 设计模式
• 设计模式-代理模式之动态代理
• 产品设计-交互原则1
• Innovus 数字集成电路后端开发设计
• 设计师的设计理念 设计师的设计理念灵感表达
• Summary Ⅰ
• 设计一个学习系统
• 计算机顶尖领域应用,全美最强 | 11个顶尖计算机工程项目
• 紫光展锐为成为世界数一数二的芯片设计巨头展开新征程