花五分钟带你了解——DDD领域驱动设计( 二 ) _DDD

经过第一轮的理论知识打击后，作者决定还是继续学习。既然理论知识太多，那就在实践中去寻找真理。
DDD到底应该怎样落地？
网上介绍DDD理论知识的相关文章很多，但真正介绍DDD如何应用在项目中的高质量技术文章就凤毛麟角了，更别提有完整示例的项目了。在这个探索的过程中，作者发现了殷浩的系列DDD教程，张建飞的COLA 4.0开源项目。
为了更透彻地掌握DDD相关的知识细节，并考虑落地DDD模式到公司的项目，还是没有采用开源项目COLA 4.0 。作者选择通过殷浩老师的系列教程，一步一步开始DDD的探索之路。
适逢公司刚好存在一个老项目急需改造，老系统是基于（dao+service）脚本式编程开发的。由于时间较远且不同时间段由不同的开发人员维护，这种老代码，呵呵呵，懂得都懂。团队讨论决定就用这个项目来做DDD的落地。
虽然一开始看了很多理论知识文档，一些技术实现细节文档。但在编写初版本的DDD设计文档时，依旧发现特别的别扭，总感觉很奇怪。本质原因还是缺乏DDD设计经验，并且对DDD的各个知识点，分层细节理解不够深入。在这个迷茫阶段，作者抱着试一试的心态，尝试加了殷浩老师的钉钉，所幸他同意了。后续就是请教学习了，请教各种理论细节的实现和注意事项。在这个过程中，有以下几点感想：

深入理解理论知识，需要落地去反复的验证，总结出来的理论知识一般具有高度的概括性，为什么是这样，不这样会如何往往需要自己去验证；
自以为已经明白了理论知识，但在实际项目使用中，却是错误地使用，比如仓库层，领域层的一些细节问题；
DDD落地困难的点还在于实现一个功能可以有不同的模式，这些模式不一定都对，但从功能实现层面来说却是都可以完成功能。比如，你在领域层直接调用仓库层保存数据，但领域层本身只是做纯内存化的业务逻辑处理，领域层是不可直接操作数据的。诸如此类的问题，导致不同的人对DDD理解不同，实现模式也不同。由于每一层的标准，实现方案不完全不同，才导致了DDD落地的复杂性。
DDD做设计时，不单是对领域层做业务设计，应该是拉通整个流程一起做设计。
实体，聚合根，这些概念在实际项目中落地到具体的业务场景时，需要反复的迭代设计。
规范无处不在，注重编程细节，小到命名，大到使用设计模式，都需要规范编码。DDD在不同的层面，需要开发人员更加注重规范，不可张冠李戴，错误如：在仓库层里面写业务逻辑。
特别感谢殷浩老师的耐心指导，技术人传道授业，简单而纯粹。这份技术人独有的编码情怀和工匠精神，很帅。

本文旨在为使用或学习DDD模式的同行者，提供一个快速的入门案例（案例gitHub地址），抛砖引玉，共同学习。目前网上还缺乏完善的DDD设计案例，本着相互探讨和学习的思想，现基于实际的案例，在脱敏处理后，详述DDD从理论到落地的流程。大致分为以下模块：