DDD你真的理解清楚了吗？统一语言建模

DDD的神器“统一语言建模”

大家好，我是范钢老师。这些年，我看到了很多团队在实践DDD。但很多团队在实践了DDD以后，都有一个疑问，DDD到底给我带来了什么好处。DDD到底带来了什么好处呢？我认为，首先是思想观念的改变。这种改变将会带来巨大的变革，那就是“主动式需求分析”。

过去，需求人员负责整理需求，研发人员负责编写代码。这表面上看非常合理、分工明确，但实际上问题非常大。需求人员不懂技术，他们仅仅是基于业务的理解记录需求，客户说什么就记录什么，我们称之为“被动式需求分析”。接着，研发人员并不了解业务，他们仅仅是按照需求文档实现功能，但其实并不知道客户真正需要什么。在整个过程中，需求的正确与否，完全依赖于客户。

然而，在整个需求分析过程中，客户说的就一定是正确的吗？其实不然。在整个需求分析过程中，客户非常清楚的是他自己的业务，业务流程、业务规则，以及业务痛点。客户提出来的每个业务需求，其实都是为了解决他的某个业务痛点。但客户不清楚的是，软件技术该如何解决他的业务痛点。因此，客户提的需求，其实是他用自己有限的知识想象的，软件系统是如何解决他的痛点。然而，这样的想象是不专业的，也不是最佳解决方案。

正因为如此，我们即使完全按照客户的要求开发出的软件，客户也不满意，因为他自己都没想清楚。然而，当他不满意时，他并不清楚，软件怎样做才能令他满意。因此，他就在现有的基础上，一点一点地试，这里改一改，那里调一调。如果不满意再改回来。这样，就使得软件研发团队的成本巨大。

在这个过程中，研发团队非常清楚软件技术，却不清楚客户的业务。这样，不论是我们还是客户，都不能把软件需求说清楚，这样就会给软件项目带来巨大的风险。所以，要解决这个问题，必须要有一方能懂得所有的知识：业务与技术。这时，我们能要求客户去掌握软件技术吗？不可能的。因此，只能让研发人员主动去学习客户的业务。当研发人员真正理解了业务，理解了客户的业务痛点，才真正能够知道，该用什么技术，怎样的设计，才能解决客户的痛点，这就是DDD的理念。

因此，DDD给研发团队带来的最大变化就是这个理念，即研发人员必须要更加深刻地理解业务。研发人员对业务理解越深刻，他们开发出来的软件才能越专业，才能让客户使用起来越满意。客户满意了，自然就不会再改来改去了。让研发人员主动去学习业务，基于业务的理解制订技术方案，来确定软件的需求，就是“主动式需求分析”。

然而，研发人员该如何去学习业务呢？自己买书学习吗，效率实在太低了。因此，最有效的学习方式就是跟客户沟通，从客户那里去学习业务领域知识。这就触动了研发人员最大的痛点，那就是不善于与客户沟通。常常客户说的话我们听不懂，我们说的话客户也听不懂。怎么解决这个问题呢？《领域驱动设计》这本书一开篇就为我们介绍了一个非常神奇的方法，那就是“统一语言建模”。

客户说的话我们听不懂，我们说的话客户也听不懂，为什么会出现这种情况呢？这就好像两个人在聊天，我说的中文，他说的英语，我们就不能够愉悦地聊天。但客户说的是中文，我也是说的中文，怎么会出现语言的障碍呢？注意，即使是中文，在不同的领域也有不同的语言，不同的专业术语。譬如，金融有金融的术语，财务有财务的术语，医疗有医疗的术语。客户说的是他们行业的术语，而我们说的是计算机的术语，那么我们彼此自然就谁也听不懂对方说的话。怎样才能解决这个问题呢？必须要让我们都说统一的、彼此理解的语言。那么是客户学习我们的语言，还是我们主动去学习客户的语言呢？显然只能是后者。

那么，我们又如何能学会客户的语言呢？当我们在听客户描述需求时，听到了一些我们听不懂的术语。这时，过去可能很自然地就把它们忽略掉了，那么我们就失去了学习的机会。当我们意识到这一点以后，今后就应当非常专注地去捕获那些我们听不懂的术语。然而，这些术语我们听不懂，又该怎么办呢？毫不犹豫地直接问客户呀。那么，直接问客户会显得我们不专业吗？恰恰相反，客户会非常理解并耐心解释，因为你就不是他那个专业的人。当你问清楚这些术语的含义，就试着用这些词语来描述你对业务的理解，进而用这些词语来进行领域建模。

当你持续这样做下去，就开始变得越来越专业，可以用比较专业的语言与客户交流业务，你们之间的障碍就消除了。当这种障碍消除了，不仅是你，连客户也越来越喜欢跟你探讨业务。这时，你就能够越来越深刻地理解业务，进而让你开发出越来越专业的软件，让客户用起来越来越顺手。与此同时，领域建模也将成为你最趁手的工具，让你在纷繁复杂的业务中快速梳理、深刻理解。当你达到这种水平时，你就变成了客户眼中最靓的仔，最愿意与你沟通交流业务，甚至愿意听从你的建议，按照你的方案来提业务需求。这样，整个形势就反转过来，不再是客户提需求，而是在理解业务以后，由我们来提需求。而这样的需求将会更加落地，能更好地解决客户的痛点，这就是“主动式需求分析”，而这种方法就叫“统一语言建模”。而这种方法在软件越来越产品化的今天，则显得越来越重要。

说说我的故事吧。曾经有一次，我在做一套中医的系统，而跟我交流需求的是一位老中医。这在过去是很麻烦的一件事情，然而我运用“统一语言建模”，一切都变得顺畅起来。当我开始聆听老中医描述需求时，非常仔细地在捕获那些我听不懂的术语。很快，我捕获了第一个术语是“表象”。我问老中医：“你刚才说的表象是什么意思？”老中医告诉我，在中医领域，医生诊断患者症状的依据统称为“表象”，它们包括“症状”（即患者对自己病情的描述）、“体征”（即医生通过“望、闻、问、切”中的“望”，观察患者得到的信息）和检测指标（即通过体检得到的结果）。这样，我开始试着用“表象”与他探讨业务。

紧接着，我又捕获了一个专业术语就是“证候”。老中医告诉我，中医的体质辨识认为，所有的疾病都是外在表现，而内因才是关键，正所谓“治病要治根”。而这个“病根”就是“证候”。我学会了“表象”、“证候”，今后就用这些术语和老中医探讨业务，然后将这些术语做到领域模型中，进而形成软件的设计。有了这样的设计，就让软件设计越来越专业，同时也使得我对业务理解越来越深，与老中医的沟通越来越顺畅，这就是“统一语言建模”的威力。

这是我按照这样的思路形成的诊断模型。可以看到，我将“统一语言建模”学到的知识最终落实到了领域模型的设计中。基于这样的设计，后面的程序设计、数据库设计都是按照这样的思路来的。与此同时，我又按照限界上下文进行了划分，“诊断模型”就是主题域，而“表象模型”、“证候模型”则是支撑域。

在此基础上，我又形成了“治疗模型”。现在，大家都在尝试着做AI人工智能。然而，在设计人工智能之前，首先通过领域模型的梳理，先深刻理解业务，并建立这样的数据模型，会为人工智能打好一个良好的基础。有了这些基础，我们就逐步开展起来“诊断模型”、“治疗模型”等人工智能的模型研究。

除此之外，今后在数字化转型中，DDD也会成为数据治理的重要方法。我会在后面的文章中，通过案例与大家分享，敬请期待。

如果对以上内容感觉有用，欢迎关注、点赞、转发！

（待续）