一、前言
这是本系列的最后一篇了，后续可能会有一些关于DDD方面新的想法和问题的解决过程的文章，会另起标题来写。
所以这篇就把之前的几篇回顾一下，也算是对自己这3个月的内容做一个总结，对之前的几篇都有看过的童鞋可以跳过本篇。
二、故事的开始
这次的这个系列是自己给自己定下的一个目标，还是下了比较大的决心的。
因为在我看来，不管是技术方案也好还是设计方案也好，DDD的价值并不局限于在它本身，它是一种抽象能力和思维方式的很好的锻炼。
还是那句话，我一直相信的是，做好了DDD，是成为一个合格的架构师的必要非充分条件。
所以一是想把自己这几年用DDD进行实战过程中的一些收获的总结并由各位来检验，二是希望自己的一些经验可以帮助到更多的人来学习DDD。
于是从16年10月底开始就决定每周一更本系列的博文，直到现在。
三、回顾
第一篇中主要讲了一些概念性的东西，并且结合本系列的Demo设计场景，先梳理出了整个上下文映射图。
这一篇我觉得每个人都应该在实践过程中有必要不断的进行回顾并思考其中的边界划分是否合理等问题，需要做出更符合当前背景的设计。
第二篇开始就进入实战了，主要内容是列举了几种比较常见的分层方式，并且把整个Demo中的项目分层确定了下来。
我想这篇可以给一些准备入门的朋友们做为一个起点，一个可以把DDD落地到手头项目中的起点。
第三篇主要讲述了在核心域中的几个领域对象的建模，和与不同上下文的交互方式的设计。
其实该篇的目的更多的是把前2篇中讲的一些概念性的东西以代码的形式表现出来，而恰恰这些是我们实际编码过程中需要耗费精力最大的地方，因为领域对象的建模是否合理，很大程度影响了整个项目的复杂度。
第四篇开始引入了领域服务和应用服务，并且通过代码的方式来体现出了2者的区别，这也是比较容易混淆的一部分概念，可能有些朋友会傻傻分不清楚某些代码到底应该放在哪里去写。
记住：应用服务负责协调，领域服务则应该是某些不属于任何领域对象的业务操作的体现。
第五篇内容相对较少，主要是引入了单元测试和对各位园友提出的一些意见进行改进。
第六篇开始引入了一个新的上下文，然后讲述了几种常见的集成方式，并且选择了其中的一种来具体实现。
在实现的过程中，建议贯彻好六边形架构的设计思想，做好防腐层的设计，以保证内聚的领域对象不被破坏。
第七、八篇从技术角度来看并没有增加新的东西，更多的是一种对领域对象进行建模的过程中笔者的一个习惯和方式，并且用代码来表现出来。更多的是对业务的实现。
第九篇主要阐述的是仓储层的设计，以及在不同的存储方案中的技术支持。本文以实战为主，举了2个常见的场景和4种解决方案，并且选择其中一种进行了实现。我想这篇还是比较有价值的，可以给大家多一些借鉴价值。
第十篇还是业务上的补缺和完善，业务主导的一篇内容。
第十一篇其实更多的是为第十二篇打铺垫。
第十二篇从技术角度来看引入了较多的东西：领域事件、领域事件的发布、和在多个上下文之间集成会遇到的问题和解决方案，并且进行了代码实现。
第十三篇是对第十二篇放到分布式场景中的考量。
到目前为止，其实在用DDD做项目的过程中涉及的基本概念和相应的实现都已经有了。所开放的Demo，麻雀虽小但五脏俱全。
四、结语
本系列的Demo，仅包含了一些核心的部分，我希望可以促使大家多一些思考。特别是一些仅仅是有兴趣的或者刚入门的童鞋，可以在这个基础之上，去实践。
我们不要盲目的追求技术的炫酷，比如那些相对偏向技术层面的CQRS、事件源等的实现。
我觉得大家在真正经过实战之后，自然会有更深的理解，为什么会出现这些技术方案，和它真正用来解决的问题是什么，并且自己能够去实现。
原创文章，转载请注明本文链接: https://zacharyfan.com/archives/205.html
关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。
如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。
