wangleimj88的专栏

我们的代码是因业务而生，如果没有业务也就没有代码，所以，代码首先要反应的就是业务，而实现业务的具体手段则要隐藏在背后。 在继续浏览下面的内容之前，请先回答一个问题，当用IDE首次打开一个陌生的工程后，让你对它产生初始认知的是什么？what？工程名？好吧，前提是这个工程名不是几个单词的首字母缩写。README？你确定每个项目都有这个文件？即使有，里面信息的用处又有多大呢。而我的回答则已经在本文的题目中了。 代码包是我们人民群众喜闻乐见的一种划分代码整体结构的工具，用好它有助于明确业

需要说明的是，不同类型的单据所使用的属性和List引用是不同的，也就是说，当单据实体中持有数据时，只有部分属性和List中是有数据的，其余都是Null。因此，在保存序列化明细项数据的同时，还要保存数据所对应的类的版本标识，如此程序才能够知道用哪个版本的明细项类（Class）来反序列化数据。由于系统中原有的一个核心实体类在业务扩展性方面的表现实在不佳，在每次新增单据类型时，如果这个新增的单据类型有明细项的话，那么就需要为该明细项创建一个明细表，并在单据实体类中添加一个明细项的一对多引用（List）。

事件溯源是以时间顺序记录所发生的事件，之后可通过这些事件得到相应对象当前状态的一种设计理念。这种设计理念从根本上颠覆了以更新方式维护对象当前状态的传统方法，其优点是保存了聚合（如果还没听说过这个概念，可以先了解下DDD）的操作历史，可以为审计和数据分析提供支持；对于事件只进行插入，也就无需锁和事务，因此性能更好。缺点是数据量会更大；需要重放所有相关事件来得到当前状态；有违大多数开发人员的习惯思维方式。 在为报销单开发支付功能的过程中发现了原支付功能中诸多不合理设计和缺陷，比如表结构（不参与查询

之前写了篇如本文题目的文章，但考虑到篇幅就没有介绍项目的重构过程，今天就把这个坑填上，以了却一块心病。 如果想用DDD，那么相关知识是必不可少的，所以先推荐几本有关DDD的书籍，从“学”开始。第一本当然是DDD的提出者Eric Evans的《领域驱动设计 软件核心复杂性应对之道》，这本花费了作者4年时间的DDD开山之作值得反复阅读。《复杂软件设计之道：领域驱动设计全面解析与实战》，这本书是国内DDD布道者彭晨阳编著，书中实例丰富，对实践很有帮助。顺便说一句，我非常喜欢封面上............

由于之前采用DDD的战略战术工具对几个项目进行了重构，在可扩展性和易维护性方面取得了很好的效果，所以在维护这个系统的过程中，结合开发、测试、上线过程中所遇到的问题以及对业务领域的理解，初步形成了重构的总体框架思路，随着对业务领域的认识不断深入，并经过数轮迭代后得到了现在的成果。https://blog.youkuaiyun.com/wangleimj88/article/details/120929931?spm=1001.2014.3001.5502