全文1700字，预计阅读时间5分钟。

导读：

继上篇的DDD系列文章第1篇：初识DDD之后，本篇介绍如何建立DDD的知识体系。让你的学习之路更顺畅。

01

—

向外看：借鉴他人的经验和思考

1.1 6本DDD书籍

书籍往往是最系统性思考的成果，具有比较高的阅读价值。DDD从2003年开始，国内外已有不少书籍了，这里通过6本书让我们看看他人是如何总结DDD的知识体系。均以思维导图方式呈现其主要内容大纲和我的简要评述。

图片

图片

图片

图片

图片

图片

1.2 从书中找共性

从上述6本书的思维导图可以得出几个发现：

  1. 凡是讲软件设计的理论，都绕不开软件设计里的面向对象思维、SOLID设计原则等普适话题

  2. 交集知识点才是重点知识。每本书频繁提到的知识点有：如何划分业务领域和模块（限界上下文），模块间如何传递信息（上下文映射）、如何把一个业务概念表达清楚（聚合）、如何分而治之地降低复杂度（分层架构）

  3. DDD知识体系是可扩展的，能和很多知识相结合。比如如何理解业务、如何规划战略、什么才是好的软件开发模式（瀑布、敏捷、极限、精益等）、如何抽象提炼知识（金字塔原理、结构化思维等），怎么对微服务架构等等

当然，看书固然重要，但书里的东西是作者认知加实践之后总结出来的东西，往往代表的是结果部分，其中知识的形成过程部分有时很难用文字表达完全代替掉。作为后来的学习者，还需要思考如何结合自身情况加以理解和消化。

02

—

向内看：建立自己的DDD知识体系

2.1 种一颗知识树

从我个人的经验看，要把学习DDD看作是一个和你现有知识融汇贯通的过程。也就是说要从一开始就建立DDD相关的知识树，把新知识点和你已有知识点产生连接才会变成你的知识。否则就像漏斗，倒进去再多最后什么也留不住。

下面是我总结的三个学习阶段：

图片

第一阶段：储备理论

学习DDD的必要理论知识。但不能太纠结细节，要想办法减轻认知负担，轻松上阵。用军事上的话来说，在战略上藐视敌人。DDD的书大多篇幅很长，不建议通篇读。先学习这些书的交集知识。我认为如下三点是交集

  1. 要解决的问题是什么：划分业务领域和限界上下文，达到清晰的业务边界

  2. 如何设计：掌握少数必要的设计元素，业务概念和关系无非是数据和行为，聚合和领域服务表达了绝大部分。

  3. 如何编码：清楚分层架构，上下文内每层该做什么，上下文间如何协作

2.2 浇水施肥

有了理论后需要结合实践，在思考和行动中修缮你对理论的理解。上图中的第二、三阶段都属于实践，在战术上重视它。

第二阶段：找连接，换思维

不管你是什么角色，团队领导，产品经理，架构师还是软件开发人员，在你的日常工作诸多环节中找一个切入点开始结合DDD。例如组织架构、开发流程、思维方式，项目的技术架构等方面，总能找到一些结合点。当你的工作遇到困难时，回到业务中去思考总是有效的。可能是你忽略思考业务了，可能是思考的还不够。但不得不承认的是现实中思维方式的改变往往是最难的。

换句话说，这个阶段也可以理解为提出问题阶段。都说一个好问题等于一半的解决方案。可以在不同方面思考并提出问题，比如两个团队的人员合作总是不顺畅，是人的问题还是业务边界不清的问题？比如项目里现有的开发流程各个环节里需要做出什么改变来适配DDD？比如大部分软件工程师都学过面向对象（Object Oriented，简称OO）编程方法，用软件中的对象来抽象表达现实生活中对应的概念。那OO中的对象和DDD中的领域模型是什么关系？

第三阶段：实践落地

实践是必不可少的一环，纸上学来终觉浅。可以从改变自己和团队的工作方式开始，每个角色都可以往业务靠的更近。比如产品经理，需求提炼过程应围绕产品理念，聚焦核心领域进行需求挖掘，和开发人员沟通需求可以统一业务语言。比如开发人员，摒除技术先入为主的思考，对支撑的业务充满好奇，投入更多的时间进行模型设计，编码设计体现出模型等等。

03

—

结语

完成了从理论到实践再到理论的闭环后，知识树的树干就有了。更多的知识积累就能进入良性循环，让这棵树充分吸收养分开枝散叶，开花结果。后续篇章将对几个主要知识点深入展开。

感谢阅读，往期文章节选：

DDD系列文章第1篇：初识DDD

傻逼曲线与个人成长