给团队做了一次技术分享，暴露了我自己

一、分享的主题和背景

2023 年春天，我们团队决定把 DDD 作为一个季度的技术学习方向。组长说：你之前在系统重构里用过，要不你来讲一次？

我答应了。当时觉得没什么问题——DDD 的那次重构项目我做了将近半年，领域边界、聚合根、值对象、领域事件，这些我都实践过，讲个两小时应该没难度。

二、备课时遇到的知识漏洞

备课的第一天，我开始把要讲的内容列大纲。

讲到”聚合根”这一块，我想写一段对聚合根的解释——什么是聚合根、为什么要有聚合根、什么情况下需要一个，什么情况下不需要。

写到”为什么”的时候，我卡住了。

我能描述聚合根”是什么”：它是聚合的入口，外部不能直接访问聚合内部的实体，只能通过聚合根。这句话我能背出来。但如果有人问我：为什么不直接操作内部实体？聚合根的约束到底保护了什么？

我发现我说不清楚。

我用了两年 DDD，那次重构就是按这个模式来的，代码也跑着。但当我试图把”为什么”这件事解释清楚，我发现我的理解里有一个漏洞——我知道怎么做，但没有真正理解背后的设计意图。

那天晚上重新读了 Evans 原书里关于聚合的章节，才把这个问题想清楚：聚合根的存在是为了维护不变量（invariant），内部实体的状态变化必须通过聚合根来协调，是为了保证聚合内部的业务规则在任何时候都是成立的。

读完之后我想：这件事为什么我两年没去搞清楚？因为我们的业务场景里，这个边界一直是成立的，没有出过问题。不出问题，就没有追究原因的动力。

三、现场那个让我卡壳的问题

分享进行到一半，有个同学问了一个问题：领域事件和消息队列里发的消息，本质上有什么区别？

我愣了大概三秒。

我当时的回答是：领域事件是业务语言，描述业务上发生了什么；消息队列是基础设施，是领域事件的一种传输方式——理论上领域事件可以通过消息队列、事件总线、或者同步调用来发布，它们是不同层的概念。

这个答案说出来之后，我不太确定是不是完整的。分享结束之后，我查了将近一个小时，确认了这个说法是对的，但也意识到我在讲解时其实是在边说边推导，而不是把一个真正理解透彻的答案说出来。

四、此后对「我懂了」这个词的新理解

这件事之后，我对”懂”这个词有了一个新的分层：

第一层：会用。 能按文档或教程把东西跑起来，能在项目里完成任务。

第二层：理解。 能解释为什么，能在遇到边界情况时做出正确判断，而不是靠”感觉对了”。

第三层：能教。 能把知识点讲清楚到让另一个人真正听懂，包括”为什么”，不只是”怎么做”。

大多数时候，我们停在第一层就觉得够了——毕竟项目在跑，需求在交付。但第一层的理解是脆的，遇到变化就会暴露。

这次备课之后，我给自己定了个习惯：每学一个新技术，在用熟之后，专门花一段时间问自己”为什么”——为什么是这样设计的，它要解决什么问题，如果不用它该怎么办。不是为了面试，是为了把理解从第一层推到第二层。

能教，是检验自己真正懂没懂最高效的方式。