自从 2004 年软件大师 Eric Evans 发表《领域驱动设计》这本书以来，DDD 的思想得到了业界的广泛认同。那么，在这 10 多年的发展历程中，DDD 的思想只有一个，但被提出来并被广泛应用的实践方法却有很多。
在前面讲解的在信息化管理系统中被广泛应用的实践方法有事件风暴法与四色建模法，它们的共同特点是以带有时间属性的活动作为中心，如事件风暴法的领域事件，以及四色原型法的时间原型。这样的设计是因为信息化系统的本质就是将真实世界的活动以信息化的形式加以管理，从而提高工作效率。
然而，除此之外还有很多软件却不然，它们没有以时间为中心的活动，更多的是描述真实世界中对象与对象的关系，以及它们之间的操作。这时，采用事件风暴法与四色建模法就不合适，因此可以采用需求讨论中建模与原型分析法。
需求讨论中建模
需求讨论中建模，是在《领域驱动设计》这本书中提出来的最原始的一种领域建模的实践方法，它是我们与业务专家在探讨业务需求的过程中，一边理解业务需求，一边绘制的草图。它将我们对业务的理解，以图形化的方式表达出来，然后与客户确认，可以让我们对业务的理解更加深刻，更加准确。
譬如，现在我们要为用户设计一个智能温控系统，为了更加准确地理解业务需求，我们与客户坐在一起进行需求讨论。
一开始，客户先描述他们的需求。
客户： 我们想要制作一个智能温控系统，它有一个 HMI（人机交互界面，Human Machine Interface），安装在室内每个房间的墙上，可以用于设定室内温度。
我们： 是每个房间都设置自己的温度吗？
客户： 是的。然后，通过一个传感器感知房间的温度，如果低于设定的温度就加热，如果高于设定的温度就降温。
我们： 是不是每个房间都有自己独立的一套控制设备，包括一个 HMI、一个传感器、一个加热设备和一个降温设备。
客户： 是的，你说得没错。同时，传感器还要感应室内的湿度、空气质量等指标，最后和温度一起显示在 HMI 上。
通过以上我们对客户需求的理解，绘制出了这样的领域模型：
在该模型中，虽然客户没有提，但我们还是在中间画出了一个控制器，因为很显然，这里需要一个控制器将 HMI、传感器、加热设备与制冷设备串联起来。这时，客户非常认可我们对业务的理解。随后，我们在这个领域模型上进行了更深入的业务探讨，又绘制出了更加细化的领域模型：
实际上，领域建模就是这样由浅入深逐步细化的一个过程。同样是 HMI，客户希望还能提供一个安装在手机上的智能 App，这样更加方便使用。有了智能 App，就需要设定你是在对哪个房间的温控器进行控制。而传感器又有各种各样的类型，有感知温度的、感知湿度的、感知空气质量的。同样是感知温度的，也有不同的实现方式，比如通过空气感知、通过地板感知，等等。基于以上这些需求，我们将传感器做出一个通用的接口，以通用的报文与控制器通讯。在此基础上，不同的传感器有各自的类型，各自的实现，但传递的都是某个“值”。
按照同样的思路，我们设计了加热设备、制冷设备，它们同样是在一个标准接口的基础上，有各种各样的不同实现。有了这样的领域建模，那么后面就在此基础上设计实现。有了这样接口的设计，就使得不同类型的传感器、加热设备、制冷设备，以统一的兼容接口，插拔式地组合使用，以适应用户各种各样的个性化需求。
最后，对领域模型进行限界上下文的分析，以及上下文地图的分析，如下图所示：
关于上下文地图的分析，可以参考第 08 讲“DDD 是如何解决微服务拆分难题的”，按照主题域和支撑域去分析相互之间的接口，形成接口协议，如加热控制域的上下文地图分析：
原文分析法
前面介绍的建模方法，是在与客户进行需求探讨的过程中就开始领域建模。方法虽好，但对于很多同学来说还是有相当大的挑战。因此，我们可以使用另一种应用更加广泛的方法，就是“原文分析法”。
原文分析法，就是在用例建模以后，在对每个用例进行描述的基础上，将用例描述的事件流按照名词与动词进行逐一分析的领域建模实践方法。
首先，我们与客户进行需求讨论。然后将返回的需求进行分析整理，将每个功能整理成用例模型，然后对每个用例模型编写用例描述，以这样的形式形成《用户需求规格说明书》。例如，在以上智能温控系统的需求规格书中，首先绘制用例模型：
然后，在此基础上，为每个用例编写用例描述，如下图温度控制的用例：
在用例描述中，将事件流中描述的业务流程，依次将名词与动词标注出来。
名词可能是领域模型中的对象，如控制面板 HMI、温控器等，也可能是某个对象下的属性，如室内温度、设定温度等，也可能什么都不是。
动词可能领域对象中的行为，如温度设定、加热、制冷，等等。是谁的行为呢？这需要基于业务去仔细分析。
最后，通过以上的分析比对，逐步形成了前文中的领域模型。
实际上，原文分析法与需求讨论中建模，往往是相辅相成的。我们可以先采用原文分析法形成一个初步的模型，然后与客户去探讨需求。这时，客户就会看着这个模型，给我们提供更多的细节，让需求的探讨更加深入。这些都会对日后的设计开发大有裨益。还是那句话，我们对业务理解得越深刻，做出来的软件就会越专业，越让用户乐于使用。
业务需求演化
根据以上的客户需求，我们把这个温控器设计开发出来了。但是，这个温控系统怎么体现“智能”呢？现有的设计还不能满足客户的需求。为此，客户又提出了一些新的需求，即智能温度控制：
当房间内没有人时，温控器停止工作以降低能耗；
当检查到房间有人时，自动启动温度控制。
拿到这个新需求以后，又该如何进行分析设计呢？首先，在用例模型中对用例及其用例描述进行变更，如下图所示：
接着，在用例模型的基础上进行领域模型的变更，如下图所示：
在对新需求的解读中，首先需要一个新的传感器——房间是否有人的传感器。接着，根据房间是否有人进行智能温度控制。这个温度控制的业务逻辑，显然与前面温度控制的业务逻辑，是软件变化的两个原因。因此，将智能控制从原有的控制器中剥离出来，单独形成了一个SmartController。
通过以上领域模型的分析，就能够非常清楚新需求所要增加的功能模块，从而做出正确的软件设计。
向物联网的转型
接着，客户在以上功能设计的基础上，还希望提供更多智能的设计。这时，仅仅从单个温控器的角度进行智能设计已经不能满足客户的需要，必须要将各个房间的温控器联网进行集中式管理。
如今，整个 IT 产业迎面而来的是 5G 技术的发展。当 5G 到来的时候，仅仅是网速提高了吗？没有那么简单，整个产业又将迎来巨大的变革，即万物互联，物联网的高速发展。物联网概念的提出也不是一年两年了，但受限于网速，一直都没有发展起来。但 5G 到来以后，将迎来一个高速的发展时期。物联网的发展将巨大地冲击那些嵌入式产业，所有的电子产品不再是单机运行，而是需要连接到云端实现互联互通。这时，将通过云端采集更多的数据，利用云端强大的运算能力，实现更多智能应用。我们所有人都要抓住这样的发展机遇，做好技术转型准备。
考虑到整个业界的发展趋势，我们的智能温控系统开始尝试向云端转型。然而，这种尝试不能规划得太远，不能脱离现实。过去追求的是架构规划，依据我们多年的从业经验，在项目设计初期就能够预测到未来多年系统的变化，并提前规划出应对这些变化的策略。然而，随着技术的快速更迭，已经没有办法准确预测未来的变化了。因此，我们采用“意图架构”。
意图架构，就是根据近期需求变化的意图，规划近期的技术架构，使其刚刚满足近期的需求。未来，当需求再次变化时，再根据未来需求变更的意图，去规划未来一段时间的技术架构。
按照这样的思想，首先以建筑为单位制订集中式管理的技术方案。将各楼层每个房间的温控设备联网，把数据都收集到集中式管理中心。这时，过去一直没有采集的数据都采集了上来。如：各加热 / 制冷设备什么时候启动与停止加热 / 制冷的指令。这样，首先可以宏观地展现各房间的总体能耗，同时可以发现那些需要频繁加热与制冷的房间，是否应当增加保暖措施以降低能耗。总之，集中式管理使得温控系统能提供更多更丰富的智能设计，更加智能地降低能耗，提供更加人性化服务。
在这样的基础上，我们又开始思考，将温控系统的数据与更多其他的数据进行比对，做更多的智能应用。譬如，通过运行在智能手机上的 App 应用，获取主人的 GPS 定位信号，在主人快要回家的时候，提前启动加热 / 制冷设备，让主人回到家时更加舒适。
未来，再从更大的范围去规划温控系统的云端部署，提供更多的智能应用。总之，物联网的发展为我们打开了一个广阔的发展空间。运用 DDD，首先站在用户的角度进行分析建模，能帮助我们更加深刻地理解业务，理解用户需求。有了这样的方法，就能准确把握市场的变化，在激烈市场竞争中站稳脚跟。
总结
DDD 的思想不仅仅应用在信息化管理系统中，同样应用在各种各样的软件研发中。但在不同的系统中，由于系统的特点不同，其实践方法也有所不同。在上一节讲解事件风暴法、四色建模法的基础上，本节又讲解了需求讨论中建模与原文分析法。不同的实践方法，其特点各不相同，适用的范围也各自不同，需要我们灵活掌握、灵活运用。
同时，DDD 也让我们在未来技术更迭的发展浪潮中，能更加准确地把握市场、把握用户需求，在激烈竞争的市场中把握先机。它是我们手中不可多得的利器，值得我们仔细学习、细心体会。
下一节将为你总结DDD领域设计和建模在产品及需求分析的应用汇总。
