19 远程智慧医疗平台（微服务+人工智能）的设计过程

前面我通过一系列案例讲解了在实际项目中是如何落地 DDD 的。这一讲，我再从更高的层面来讲解，DDD 如何从战略层面规划一个智能系统的建设。

在本专栏的一开篇我就谈到了，领域驱动设计是软件核心复杂性的应对之道。在一个业务单一的系统中，领域驱动设计的优势并不大，反倒使得设计开发比较麻烦，没有那么敏捷而直接。然而，随着软件业不断发展，现在的软件系统规模越来越大，面对互联网的大型、综合性业务系统越来越多。业务与技术的双重复杂性，带给软件开发团队前所未有的严峻挑战。在这样的形势下，DDD 无比优越的特性逐渐体现了出来。

很多人在质疑，DDD 与传统的 OOA/D 有什么差别？诚然，DDD 是对面向对象思想的传承，但这里最大的差别在于，它创新性地提出领域建模的思想，将业务分析与技术实现予以分离。这是一种“分而治之”的思想，在业务需求不断变更的过程中，我们做领域建模思考的是业务，与技术无关。这样，在纷繁复杂的系统变更过程中，才能对业务及其设计看得清楚，从而做出正确的设计。

同时，DDD 在复杂系统中的设计又分为战略设计与战术设计。

• 战略设计通过限界上下文从全局的角度规划整个系统的业务模块；

• 接着，逐步细化，对每个模块开展事件风暴会议，进行领域建模；

• 最后，在这些设计的基础上，逐步落实到每个模块的数据库设计与微服务设计，以及它们需要涉及的分布式技术与云端部署。

接着，我们以“中医远程智慧医疗平台”为例，来讲解这样的设计过程。

基于业务的战略规划

中医远程智慧医疗平台，是一套集互联网、云计算与人工智能为一体的大数据医疗平台。该平台首要的需求就是建设一个智慧诊疗数据模型，它通过人工智能与数据建模，辅助医生进行诊断治疗。医生在接诊患者的过程中，输入患者的症状，那么该数据模型就能帮助医生进行诊断，并制订治疗方案。

然而，智慧诊疗数据模型如何对外提供服务呢？它首要的服务对象是各地的医院和诊所。我们既要有自己的诊所管理系统，为各地诊所提供帮助，同时还要通过开放接口与第三方的医院 / 诊所系统对接，从而有效地拓展系统的服务范围。智慧诊疗数据模型在对外提供服务的时候，要面对互联网高并发、高可用等非功能性需求，所以需要一个云端服务平台予以支持。

该平台的诊所管理系统，其定位是面向千千万万的社区诊所。依据这些社区诊所的特点，将其规划为一个搭建在云端的、连锁式的诊所系统。正因为搭建在云端，医生不必局限于本地诊所，而可以通过互联网实现远程接诊。因此，将医生从各个诊所系统剥离出来，形成一个独立的医生端。这样，医生可以通过医生端，同时在多个诊所进行远程接诊，更加合理地利用有限的医疗资源而不再受地域的限制。

医生既然能从各个诊所中剥离出来，通过医生端在各个诊所接诊，那么也可通过患者端 App 直接为患者接诊，这就有了患者端。这样，患者在生病时，还可以通过患者端 App 填写一个问卷，描述自己的症状，然后由智能诊疗模型为患者进行一个初步诊断。有了这个初步诊断，了解患者大致得了什么疾病，就可以通过患者端，有针对性地为患者推荐相关的医院与医生，从而有针对性地进行网上预约。

最后，在医生接诊开药结束后，根据不同的来源：

• 在诊所接诊的患者在诊所中缴费、取药；

• 在 App 接诊的患者通过健康购物网站远程进行配送。

智能诊疗模型就会根据不同的数据接入来源，将诊疗结果返回给不同的数据来源方。

以上就是基于业务建模，对中医远程智慧医疗平台的规划。通过这些规划，就将整个系统划分成了：智慧诊疗数据模型、远程医疗云端平台、诊所管理信息系统与健康产品购物网站。同时，在诊所管理信息系统中，又划分出了医生端、患者端、诊所端与平台端。

• 医生端，是医生从诊所系统脱离出来，独立的接诊工作台；

• 患者端，是患者智能 App，可以进行远程预约、远程就诊等操作；

• 诊所端，就是为各地社区诊所提供的连锁式诊所管理信息系统；

• 平台端，则是整个医疗平台中管理各个医生、患者、诊所的管理平台。

基于限界上下文的领域建模

有了以上基于业务的规划，就将这个庞大的系统规划为多个不同的限界上下文，分配给多个研发团队。在这样一个规模化，甚至分布于多个城市的分布式团队中组织开发：

• 既要讲究独立性，即按照业务独立性将系统划分为不同模块，分配给多个团队独立开发；

• 又要讲究协作，即单一职责，你做你的职责，我做我的职责。

当你在完成你的业务的过程中，需要执行某些我的职责的事情，必须调用我的接口，而不是你自己去实现。只有这样，才能在日后的变更过程中，尽量避免一个需求需要多个团队都要同步变更的状况。这对于大规模、分布式团队来说尤为重要。

接着，每个团队开始独立工作。首先是独立地召开事件风暴会议，它可以和敏捷开发相结合，成为迭代计划会议前准备工作的一个部分。现在，越来越多的团队都在采用敏捷开发，而多个需要协作的敏捷团队必须采用一致的开发周期，统一步调地开始迭代计划会议，以及结束一个阶段的迭代。在上一个迭代结束时，除了有迭代的成果展示，还要通过事件风暴会议，开始准备下一个阶段的迭代。

这时，每个团队在事件风暴会议中，不仅要通过建模，分析清楚自己的领域模型，还要通过主题域与支撑域的分析，清楚需要哪些团队提供什么样的接口支持（详见第 08 讲“DDD 是如何解决微服务拆分难题的”）。这样，在各敏捷团队之上有一个“项目群层”的敏捷组织机构，将各团队组织在一起进行迭代、开计划会议。这时，各团队会通过这个机会提出对其他团队的接口需求，而其他团队会跟你协商接口的标准，并作为那个团队的用户故事放入迭代计划中。通过这种方式，不仅将领域驱动与敏捷开发结合在了一起，也使得各团队之间既能保持独立性，又能相互协作，组成一个有机的整体。

基于领域的战术设计

有了前面的一系列规划与协调，整个系统分为哪些模块、交给哪些团队、相互之间如何接口，及其各自的迭代计划都制订出来了。这样，每个团队就可以彼此独立地开展各自的工作。

首先，各团队在前面事件风暴的基础上开展各自的领域建模工作。譬如，中医远程智慧医疗平台分为智慧诊疗数据模型、远程医疗云端平台等几个模块，分属多个团队再进行设计开发。这时，智慧诊疗数据模型团队开始了他们的领域建模工作。通过统一语言建模，他们将“症状”改写为“表象”，将“疾病”改写为“证候”，用更专业的中医词汇来表述业务需求，分别形成他们的用例模型、用例描述与领域模型。

其中，用例描述是对用例模型（如上图所示）中每个用例的参与者、事件流等详细信息的描述。在敏捷开发中强调轻文档，然而开发过程中必要的文档还是要写的，而以用例描述为格式的需求规格书就是必写的文档之一。接着，团队成员就可以在用例模型的基础上理解业务，开始领域建模。领域建模有很多实践方法，事件风暴只是其中一种，还有原文分析法、四色建模法，等等。

如上图，这是开发团队基于“诊断”这个应用场景的四色建模。粉红色的“诊断”是时间原型，它是某个时间发生的某件重要的事件，是领域建模的核心。围绕着时间原型，有很多与它相关的参与者 - 地点 - 物品原型，表示与事件相关的人物、地点、物品，用绿色表示，简称 PPT（Party / Place / Thing）。

在诊断过程中，有医生与患者，他们在这个事件中扮演的角色就是医生与患者。然而，现实世界中的表象、表象组、子证候与证候有很多，而此次诊断过程中的患者只有这些表象、表象组、子证候与证候。因此，黄色的患者表象、患者表象组、患者子证候与患者证候，表示的是在此次事件中参与的角色原型。此外，蓝色原型是对 PPT 原型的补充说明。

最后，在这个场景中的所有领域对象，按照限界上下文划分为三个部分，只有“诊断模型”才是这个场景的主题域，其他两个都是支撑域。

基于领域建模的设计实现

最后，将以上领域模型的设计，最终落实到技术实现与编码。譬如，智慧诊疗数据模型又分为以下部分。

• 诊断治疗研究平台：一个专门为医学专家提供数据建模的平台。

• 诊断治疗数据模型：一个分布式大数据平台，进行各种机器学习运算。

• 智能诊疗服务接口：一个开放服务接口，为第三方的医院 HIS 系统、诊所管理系统的医生端与患者端，提供智能诊断治疗的数据服务。

在这样的基础上进行技术架构设计：

• 诊断治疗研究平台是一个微服务，并通过 MySQL+Redis 存储模型数据；

• 诊断治疗数据模型是一个大数据平台，通过 Hive 数据库存储并处理采集的海量诊疗数据，并将最后的运算结果导入 Redis，供应用端调用；

• 智能诊疗服务接口要面对高并发、大数据，它通过微服务设计在云端进行分布式部署，并将海量的诊疗数据保存到 TiDB 的 NewSQL 数据库中，从而能够扛住高并发、大数据的系统压力。

此外，其他的业务团队也同样按照这样的分析设计步骤，就可以将这样一个大规模的业务系统有条不紊地开发出来，最后部署在云端 Docker+K8s 的运营环境中，将我们的业务逐步开展起来。

总结

DDD 是对软件核心复杂性的应对之道。软件之所以维护越来越困难，就是因为随着业务的不断拓展，将业务与技术混杂在一起去变更维护，我们的大脑就受自身的局限而越来越无法应对这其中的复杂性，从而做出许多错误的设计，使系统变得越来越难于维护，将团队置身于越来越大的风险中。因此，DDD设计的核心就是“分而治之”。

首先，通过业务建模将业务与技术分离，业务变更就思考业务，技术更迭就思考技术，设计就变得清晰而易于做出正确设计。接着，通过限界上下文的划分，不同的模块，不同的团队，各司其职，就使得系统的复杂性下降，风险变得可掌控。但模块与团队的划分又会带来组织的复杂性，因此通过与规模化敏捷的结合，就能使团队的协作变得顺畅。只要有了这些基础，我们才能够构建更大规模的系统，迎接未来物联网、大数据与人工智能的挑战。

下一讲将为你讲解智能温控系统的 DDD 设计过程，到时见。

---

20 智能温控系统（嵌入式+物联网）的 DDD 设计过程

前面为你讲解的 DDD 落地的案例都是在服务端 Web 应用，或者信息化管理系统，那么 DDD 是否还可以应用在其他领域呢？毫不夸张地说，DDD 可以应用于所有软件研发领域，绝不局限于以上这些。所以这一讲，我们来看一看 DDD 在嵌入式研发的领域，以及嵌入式系统向物联网领域发展，DDD 所扮演的作用。

自从 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 为你打开通向光明未来的大门

本专栏到这里就结束了。实际上，DDD 在 2004 年就提出来了，关于它的话题也有很多大神都讲解过。但 DDD 最大的难题是落地，许多团队在实践 DDD 的过程中都遇到了各种各样的难题，甚至失败的经验。所以，这个专栏把更多的重点放到了落地实践上。

• 它从战略战术的不同层面，讲解了很多的案例，以及 DDD 是如何开展的；

• 从实战的角度，将 DDD 落地到微服务，讲解了如何通过 DDD + 微服务的架构，解决当今软件发展规模化的问题。

在这个过程中，通过 DDD 进行规模化的业务分析，通过微服务进行规模化的设计开发，通过规模化的敏捷进行团队组织，使我们能够对大规模化的软件系统进行更加合理的设计，用更低的成本进行维护，从而可持续地发展。

然而，DDD 要真正地落地，难点在于需要研发团队做出以下几个方面的改变。只有做好这几个方面的改变，才能领悟 DDD 的精髓，发挥 DDD 的优势，把 DDD 真正落地。

让研发团队更深刻理解业务

DDD 的精髓就在于业务领域建模、统一语言建模，这是 DDD 区别于其他设计方法的核心。过去，业务需求是软件研发最大的风险，而这个风险的核心是研发人员不理解业务。研发人员被动地理解业务，你怎么说我就怎么做，并不真正理解业务。这样导致的结果就是，我们的软件做得不专业，不能解决用户的痛点，就不能在激烈竞争的市场中获得优势。

在激烈市场竞争中，我们开始敏捷转型，就是要将软件研发扁平化，缩短软件研发过程的环节。实践 DDD 就是将研发环节从“客户 → 需求人员 → 研发人员”精简为“客户 → 研发人员”，需求人员更多转型为组织、协调与归档的作用。在需求分析过程中，研发人员应当更多地参与对需求的细化。这样，研发人员对业务理解越深刻，结合他们对技术的理解，就能够更好地利用技术，制订出更加合理的方案，提高用户体验。

接下来的难题就是如何让研发人员提高沟通与理解能力，快速而深刻地理解业务，那些统一语言建模、事件风暴法、四色建模法、原文分析法等 DDD 的实践方法，都是帮助研发人员去做这些事情，需要我们仔细学习，在工作中勤加练习、熟练掌握。

准确理解 DDD 中的概念

实践 DDD 的另一个难题是准确理解 DDD 中的诸多概念。实际上，DDD 有相当大的学习成本，因为它的很多概念都比较抽象。正因为 DDD 要应对的是软件的复杂性，才会通过领域建模去抽象复杂业务，让复杂业务得到简化，从而简化软件的设计，这个过程本身就是不简单的。因此，我们学习 DDD，首先就要把设计做到位，准确理解那些聚合、仓库、工厂、领域事件等基础概念，并在设计实战中做出正确的设计。

这里，特别要提醒你的是，对“聚合”的理解。在与学员的交流中，很多都是对“聚合”错误的理解以后，做出错误的设计，将不是聚合的关系做成了聚合，导致程序设计既复杂又别扭。这里一定要引起注意。

另外，DDD 不是孤立的，也不是静止的，它也在发展。因此，在 DDD 的设计实践中，也应当与微服务、分布式、大数据等当今主流的技术相结合，将 DDD 的设计理念最终落实到技术上。

将 DDD 融入敏捷开发中

自从 2004 年 DDD 被提出来以后，它对整个软件业的发展起到了非常积极的作用。在那之后提出来的许许多多设计方法与技术框架，都有 DDD 的影子，这也包括许多的敏捷开发实践方法。如今，许多团队都在实践敏捷开发，但敏捷开发的落地对开发团队的设计能力、设计质量，提出了非常高的要求。因为每 2 ~ 3 周的敏捷周期，都是在对上一个版本的更新。如果设计质量跟不上，更新速度越快，代码退化就越快。代码质量下降了，还能敏捷得起来吗？

采用 DDD，其目的就是要在越来越复杂的系统维护过程中，始终保持其设计质量。因此，团队在实践敏捷的过程中，应当将 DDD 融入其中，在每次迭代计划前进行业务建模，在迭代过程中基于领域模型设计变更、快速迭代。这样，才能在快速迭代的过程中始终保持设计质量，真正将敏捷开发落地下来。

DDD 落地最大的难题是架构

我始终认为，DDD 最大的罩门是架构。DDD 的作者为我们提出来了一个非常好的软件设计思想，那就是业务领域建模。但基于这样的设计思想如何落地到软件的架构设计上呢？DDD 的作者并没有明确，或者说只有一个大的框框。这既是一个坏事，也是一个好事。

• 说它是坏事，因为很多的团队在落地实践 DDD 的时候，苦于不知道怎么架构而困惑不已，这为 DDD 的落地实践蒙上了阴影。

• 说它是好事，是因为这为我们提供了一个非常广阔的发挥空间，并且许多大师都在此基础上提出了他们的思路，包括整洁架构、六边形架构。我在此基础上也提出了我的思路，并创造性地提出了单 Controller、单 Dao、通用工厂与仓库等设计，并分享了我的代码。

此外，我还不断地求索，不断更新我的代码库，为你提供更多的帮助。也希望你在今后的日子里，持续关注，多多交流，在 DDD 落地实践的道路上并肩前行。

结语

最后，在这新春即将到来之际，给你拜一个早年，祝愿你在新的一年，工作顺利，再上一层楼。希望正在实践 DDD 的小伙伴，在新的一年实现对 DDD 的落地实战。在这个过程中，你可能会彷徨与困惑，苦苦挣扎与求索，但最终会达到胜利的彼岸。也希望我能成为你的良师益友，告诉我你的困惑，帮助你解决问题，并携手共同进步。最后希望你动动手，将这个专栏分享给更多的小伙伴，给他们帮助，给他们知识。

最后，我将邀请你为本专栏进行结课评价，你的每一个反馈，我和拉勾教育都会关注且认真对待。希望你能为自己的学习之旅画上一个完整的句号，点击链接，参与课程评价，编辑同学会随机抽取 5 位同学送精美礼品。

---