DDD你真的理解清楚了吗？再谈非敏捷实践

再谈非敏捷团队的实践

大家好，我是范钢老师。上期通过一个实战案例，讲解了嵌入式团队如何实现DDD的实践。然而，除了嵌入式、桌面端团队以外，也有许多传统的业务系统开发团队。对于这些团队，又应当如何通过转型，实践DDD呢？我认为一定要从当前的实际出发，根据当前的研发流程，既不能变化太大，又能够有效地运用DDD的设计思想，有效地提高团队的研发效能与代码质量。也就是说，一定要在成本与成效之间找到一个最优的性价比。那么，我们可以先从当前的研发流程开始，探索DDD的最优实践。

在很多传统的研发团队中，每次的研发都是从需求研讨与编写需求文档开始的。产品经理和需求分析人员首先到客户那边去开需求研讨会，收集大量第一手的需求资料，然后在这样的基础上开始理解并编写需求文档。经过反复地需求研讨，最后形成一份双方都认可的需求文档。在这样的基础上，双方签字并进入研发阶段。按照这样的流程，有没有合适的DDD实践与之对应呢？当然是有的。

首先，在需求研讨会中，可以使用“统一语言建模”的方法与客户探讨需求，并快速学会客户的语言，理解客户的业务，这种方法在上一期已经演练过了。很显然，在客户现场绘制领域模型，还要让客户能够理解，还是有相当的难度的。除此之外，还有没有更加容易的方法来实践DDD呢？今天，我们就来探讨一下另一个DDD的实践方法：原文分析法。

譬如，我们现在要研发一套远程智慧医疗平台。产品经理带着团队，首先走访了客户方的领导，他首先从顶层开始描述他的一整套规划。

客户领导：我们这里有一些患者的病历数据，包括患者的症状、医生的诊断及相应的处方。我想通过这些数据做一个诊断治疗模型，帮助医生进行辅助诊疗。

产品经理：有了这个模型，给谁提供服务呢？

客户领导：我们有很多的诊所，对接到他们的诊所系统中，为其提供服务。

架构师：机器学习需要不断获得新数据，不停学习，然后才能判断得越来越准确。是不是可以把分散在各地的诊所系统都统一部署在云端，建立连锁式的诊所系统。这样，不仅可以降低维护成本，还可以更方便地获取病历数据，为模型不断地学习提供方便。

客户领导：嗯，这是一个不错的思路（领导表示认同）。

产品经理：有了连锁式诊所系统，医生是不是就可以进行远程接诊？这样，医生可以同时在多个诊所接诊患者。

业务专家：也是啊，那医生在哪个诊所就不重要了，可以直接建立一个医生接诊平台，与各个诊所相互独立。然后，患者有一个App，上面既可以预约医生，又可以直接与医生接诊。医生在接诊平台接诊患者，通过智慧模型辅助诊疗……

通过这一番的探讨，我们与客户的高层首先形成了一个共识，要构建一个远程智慧诊疗的平台，以及相应的愿景、使命、目标，最后把这个系统划分出了智慧诊疗、医生端、患者端、诊所端、平台端，以及健康购物的这样几个子系统。通过此次的访谈，我们绘制出了第0层的用例模型。在该模型中，有诊断治疗、医生接诊、患者就诊等用例，每个用例就是一个子系统。在这样的基础上，就开始由粗到细地逐步开始业务拆解。

在后面这段时间里，我们走访了客户的多个部门，召开了多场需求研讨会，对每个子系统的业务需求进行仔细地分析和探讨，一步一步地落实。白天探讨业务需求，晚上将这些业务需求形成用例模型。最后，基于我们对业务的理解，将一个一个的用例形成用例描述。

这是对“诊断治疗”这个用例展开的第1层用例模型，它模拟了医生看病的整个过程。其中，从“问诊”到“主述问诊”、“序列问诊”、“联想问诊”、“补充问诊”，是从用例到子用例的过程。通过子用例的设计，就可以使一些比较复杂的流程，描述的时候变得有层次而清晰起来。接着，开始为每一个用例编写用例描述：

在这个用例描述中，本来问诊是一个比较复杂的流程，需要非常多的步骤与环节，然而通过子用例，将一些相对独立的流程放到子用例去描述，那么该用例就得到了极大的简化，从而使得阅读变得清晰起来。

在完成了用例的分析与用例描述的编写，就可以将这些系统要实现的功能，以及每个功能的业务流程分析清楚了，它被称之为“动态模型”。然而，在这些业务流程中，到底都有哪些业务对象，它们都有哪些关系与操作呢？这就是领域模型，也被称之为“静态模型”。有了用例模型，为什么还要分析领域模型呢？因为业务信息系统的本质就是数据，所有的业务流程都是在围绕着对数据的处理、操作，以及最终的存储。这些数据是什么数据结构？它们之间什么关系？对它们有什么处理？这些都是通过领域模型分析来逐步落实的。因此，从需求到开发，如果缺少了领域模型，设计就会严重脱节，设计质量不高，后期运维就会变得困难。

但是，如何将用例模型转化为领域模型呢？这里的实践方法就是“原文分析法”。原文分析法首先提取用例描述中事件流的名词和动词。名词可能成为领域模型的对象或属性，也有可能什么都不是；动词可能成为领域模型中的方法，到底是谁的方法呢？需要基于我们对业务的理解，仔细分析。

譬如，在以上案例中的“问诊”用例，将该用例描述的事件流中，所有名词与动词都标注出来，如图：

从这里可以提取出“医生”、“患者”、“病情”、“表象”、“联想关系”、“互斥关系”等。这些名词到了领域模型，有可能是领域对象，也有可能是领域对象中的属性。什么时候是领域对象，什么时候是对象中的属性呢？关键看该事物在我们的系统中是如何记录它的，如果是一个简单的数字、文本、时间，那么就是对象下的属性；如果该事物还有属性，还要做更详细的描述，那么就是对象。

譬如，用户档案中的地址，它是真实世界中的事物，但在领域模型中是对象还是属性呢？关键看我们如何记录地址的。如果在系统中，地址仅仅记录成一个文本，那么它就是用户对象下的一个属性。如果在系统中要详细记录地址，包括在哪个省、市、县、乡镇、街道，那么它就是一个领域对象。除此之外，有些名称可能是某个属性的内容，譬如“联想关系”、“互斥关系”，它们都是表象间关系的内容。

接着，从以上用例描述中还提取出了“询问”、“形成”、“存在”、“发现”等动词。这些动词可能是某个领域对象中的方法，也可能什么都不是。最关键的是，这里我们要建设的是信息系统，因此那些在系统之外的行为，或者在前端进行的操作，如选择某个选择框、点击某个按钮，都不是领域模型所需的行为。只有那些后台需要操作的行为，才是领域模型所需的方法。那么是哪个对象的方法呢？我们根据职责来确定。最终，形成了这样的领域模型：

很显然，这样的领域模型是非常粗糙的，但它可以成为一个开始。首先，我们不是从一个用例中进行提取，而是在多个用例中进行综合。其次，后面我们还会非常针对性地去与客户沟通，了解更多的细节。同时，客户拿到这个领域模型以后，也清楚地知道还需要给我们哪些资料，用以补全整个模型。因此，后面的整个分析设计工作，都是围绕着用例模型和领域模型展开的。通过无数次与客户的沟通，我们就由粗到细地逐步把整个系统梳理清楚了。后面就可以基于用户模型与领域模型的设计，指导后续的设计与开发工作。

通过以上的设计实践，我们来回顾一下，它与传统开发模式的差别。传统开发模式在需求阶段是用大段大段的文字编写需求文档，但缺乏相应的格式，想到哪里写到哪里，需求分析的质量就不能得到保证。现在，采用用例模型，按照相应的格式进行编写用例描述。当我们将用例描述中所有的数据项都填写完成，那么这个需求方方面面的内容都分析全面了。也就是说，将过去编写的需求文档，现在按照用例描述的方式，转换了一下思路与格式，完成需求文档的编写。

此外，与传统开发模式不同的是，现在在需求与开发之间又增加了领域模型的创建过程，它是介于需求分析与软件设计之间的一项工作。有了这项工作，就可以更好地将需求转换成设计，有效提高软件的设计质量。

随着AI技术的发展，未来越来越多的设计编码都要由AI来完成。采用以上这种原文分析法的DDD实践，利用AI强大的语言理解与生成能力，可以更快更好地完成业务系统的研发工作。那么，AI+DDD又应当怎样软件研发呢？我们下一期来好好探讨一下吧。

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

（待续）