本文书接上回《DDD是软件工程的第一性原理？》，关注公众号（老肖想当外语大佬）获取信息：

1. 最新文章更新；

2. DDD框架源码（.NET、Java双平台）；

3. 加群畅聊，建模分析、技术实现交流；

4. 视频和直播在B站。

假DDD的特征

在开始之前，考虑到目前关于DDD的资料非常多且杂，我们需要具备分辨的能力，确保不被误导。看过本系列文章的朋友，对我们是如何看待DDD的会有一定的感受，这里我们列举一下我们认为的假DDD的特征，供大家参考：

1. 堆砌抽象词汇，让人不明觉厉的

2. 说DDD只有高级开发者才适合的

3. 说DDD很难落地的

4. 说只有复杂项目才适合的

5. 说只能凭经验的

适合人群

首先我们认为“领域驱动设计是一种价值观”，那么理解并能够实践DDD的前提，认可这种价值观，既然如此，说明第一步的起点，是没有门槛的，只要你主观上认同即可，所以我们认为DDD适合软件工程工作相关的各个角色来学习和实践，包括但不限于：

1. 期望从事软件领域的在校学生

2. 各个层级的软件工程师

3. 产品经理

首先软件工程师得懂DDD，这是毋庸置疑的，我隐约有一种感觉，真正的DDD就是软件工程的唯一正解，不少后端老司机一直苦于随着时间的推移，系统代码快速腐化的问题，而DDD正是对抗这种腐化的底层逻辑，是软件工程的第一性原理。

对于学生群体，我接触的案例证明，对于软件领域的新人，反倒更容易理解和接受DDD，这是因为目前主流的软件设计指导，很多都指向了与DDD相反的方向，新人因为没有被这些信息所误导，没了先入为主的思维枷锁，很自然地容易接受更有收益的软件设计思想。

软件工程师最喜欢的产品经理，大概率是懂一些技术的产品经理，而如果对DDD的概念有所理解的产品经理，我相信在需求分析、产品设计、模型设计方面能够与工程师更容易相互理解并建立共识，大家一定还记得之前文章所说的“拟人化建模沟通法”，在这里更是能发挥巨大的作用，使得“需求-模型”的一致性得到更好的保障。

学习路径

下图展示了一个学习的循环迭代，我认为可行几点如下：

1. 学概念，通过系列文章、视频，构建基本概念认知

2. 学实践，使用DDD框架做代码练习

3. 做验证，一个教练指导并不断地实战体验，迭代认知和行为

学概念

我们认为DDD的概念是具体的，是容易理解和实践的，如果你有通读本系列的前文，那么一定会有所感受，《老肖的领域驱动设计之路》，其中关键的概念观点包含但不限于：

• 领域驱动设计是一种价值观

• DDD原则

• 边界明确是最重要的事

• 一致性比正确性更重要

• DDD是软件工程的第一性原理

• 系统的复杂度来自元素的数量和元素之间的关系

• 复杂度守恒定律

• 拟人化建模沟通法

• 不要复用

• 万能模型之“命令-事件”

• 如果写代码别扭，大概率是建模出了问题

学实践

学实践，就是不断地建模设计、代码实现，目前我们已经为Java、.NET生态分别提供了DDD战术框架，基于战术框架，并配套了工程模板，期望能够帮助你的团队在没有技术负担的状态下体验DDD带来的优势和收益，从而增强团队的DDD认知：

Java：https://github.com/netcorepal/cap4j

.NET: https://github.com/netcorepal/netcorepal-cloud-framework

关于教练

首先教练不是必须的，但一个好的教练，可以让你大大加速对DDD的认知和应用，教练的核心作用就是：

1. 引导认知理解

2. 教授实践方法

3. 验证学习成果

那么对于一个好教练，我认为最关键的就是：能够判断决策（需求分析、建模设计、代码实现）是否符合DDD价值观。要做到这点，那么一个好教练大概率满足以下特征：

1. 对DDD的理解准确

2. 有实践的成功经验

哪里找一个好教练呢？（广告时间）在你眼前就有这么一位，关注我，我在直播间就是扮演教练的角色，欢迎互动交流。

视频与直播：

https://space.bilibili.com/6733407

如何判断成果

学习过程中，很重要的就是成果的正向反馈，关于DDD的学习，以我的经验来看，虽然无法给出明确的可量化的指标，但下面几点可以帮助你从主观上判断是否有进展：

1. 对需求和系统有掌控感了

2. 需求-模型-代码越来越一致了

3. 写代码感觉丝滑了

4. 代码BUG率有显著的改善

最后

欢迎交流实践经验，持续提高开发者的幸福感。