不容错过！什么是领域驱动设计？为什么落地这么难？

技术分享 3年前 (2022-08-26) 0 999+

引言

领域驱动设计并不是新的架构设计理论，从Eric Evans提出至今已经有十多年历史。由于微服务架构的兴起，DDD常用于指导微服务边界划分，并重新广泛进入软件研发大众的视野。DDD的理念及应用普及在国外相对成熟，在国内尚处于初期发展阶段。国内的很多社区以及企业组织内部近几年对于DDD的探讨和应用逐渐火热，许多架构师以及开发人员对DDD充满了学习和实践的热情。而像敏捷一样，不同团队对其认知水平和实践水平不尽相同，有的成功，大多数可能是失败的。

领域驱动设计（Domain Driven Design），简称DDD， Eric Evans 2004年的《Domain-Driven Design: Tackling Complexity in the Heart of Software》一书中第一次提出。领域驱动设计是一种用于指导软件设计的方法论，也是一种设计思维方式，用于解决软件复杂性问题，旨在加速那些必须处理复杂领域的软件项目的开发。

实践DDD的第一步不在于如何编写代码，而首先需要拉齐对领域驱动设计的认知。后续的系列文章将围绕领域驱动设计进行不同视角探讨，以期帮助大家对其有更深入的认识，并能应用的实际的研发工作中。

聊聊问题空间、解空间、领域模型

问题空间和解决方案空间

问题空间：Problem Space，是当前环境下业务所面临的一系列问题和问题背后的需求，通常是业务和产品领域专家主导问题、需求的收集描述和分析。问题空间框定了我们要解决的问题的上下文，这种上下文环境不是软件工程或是领域驱动所独有的，而是通用的共性的元素。工程实践必然处于某种上下文环境之下。

解决方案空间：Solution Space，解决方案空间是针对问题空间的解决方案，属于工程实现阶段，由技术专家主导方案设计。

软件开发过程，本质上可以看作是问题空间到解决方案空间的一个映射转化：问题空间，找出业务挑战及其对相关需求场景用例分析解空间，通过具体的技术工具手段来进行设计实现

领域、模型和领域模型

领域：Domain

“领域”是“知识或活动的集合”，相对于软件系统而言，领域就是软件应用所要解决的现实问题区域。领域对应于问题空间，是一个特定范围边界内的业务需求的总和。

领域模型：Domain Model

抽象是一种化繁为简的能力，是人类认识世界的利器，也是一种生物本能。在有限的脑容量的前提下，人类不可能存储记忆所有的细节，海量信息已经超出人脑存储限制而无法容纳和有效获取。抽象使得人类可以屏蔽无关细节信息，抽取高层的有效信息进行记忆存储。试想，如果脑机接口技术有所突破，在人脑背后链接的是海量的高效的计算机集群，这种无限的存储、计算和检索能力的增强，“抽象能力也许会被弱化”。

模型被用来表述人们所关注的现实或想法的某个方面，本质上是一种抽象过程的产物，把与解决方案密切相关的方面抽象出来，而忽略无关细节。

聚焦在软件工程领域，要想构建满足需求的软件系统，开发团队需要软件面向的领域所涉及的知识可能非常庞大和复杂，而模型正是解决这种信息超载问题的有效工具。

对领域进行模型设计的过程就是领域建模，领域建模的目的并非是要建立一个百分之百符合“现实”的模型，理论上，我们也无法实现这种对现实的完全建模，而只能是对现实某种程度的模拟。

领域建模的输出即领域模型，领域模型是针对特定领域里的关键事物及其关系的可视化表现，属于解决方案空间范畴。为了准确定义需要解决问题而构造的抽象模型，为软件系统的构建目标统一认知，是业务功能场景在软件系统里的映射转化。领域模型并非领域专家头脑中的知识，而是对这些知识进行严格的组织和有选择的抽象。

同时，领域模型并非某种特殊的图、文字或者代码，而是他们所传达的思想，图、文字或代码都可以作为模型的表示或传达形式，但他们不是模型，而是不同维度的模型视图。

领域驱动设计

领域驱动设计强调领域模型的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。领域驱动设计首先从业务需求中提炼出统一语言，并建立领域模型指导着程序设计以及编码实现；最后，又通过重构来发现隐式概念，并不断解决领域领域模型相关的新问题。本质上，领域驱动设计也是从问题空间映射到解决方案空间。

领域驱动设计结合了宏观和微观两个层面的设计，分别对应于领域驱动概念中的战略设计和战术设计。

领域驱动设计：战略设计

战略设计的初衷是要保持模型的完整性，主要从下面两个方面来考量的：

问题域方面：将问题规模进行拆解，划分为不同类型的子域，识别出核心领域与其他子领域。

解决方案层面：划分限界上下文和上下文映射对问题域进行合理的分解，确定上下文边界以及它们之间的关系。

领域驱动设计：战术设计

战略设计的初衷是要保持模型的完整性，通过战略设计将整个软件系统分解为多个限界上下文，然后对每个界限上下文进行战术设计。对每个限界上下文进行战术设计。Eric Evans提供的模型驱动设计的构造要素以及要素间的关系如下图所示：

实体：Entity，不同于通过属性进行定义的传统对象，实体对象通过唯一标识进行区分，且具有持续的生命周期。
值对象：Value Object，值对象是具有属性且不可变的对象，但没有唯一标识。
领域事件：Domain Event，领域事件用于记录系统内的模型活动相关的离散事件，虽然系统内所有事件都应该能够被跟踪，但只有被领域专家关心的事件类型才创建领域事件。
聚合：Aggregate，聚合对象是实体和值对象的聚合，聚合具有一个唯一的根，即聚合根。外部对象不再直接访问聚合内部的单个对象或者实体，而是直接访问聚合根，并使用聚合根将指令传递给对应的分组。
领域服务：Domain Service，某些领域逻辑不适合分配给某个特定的实体对象，可将其这些操作封装成领域服务
资源库：Repositories，资源库不是配置库，它提供一个全局接口来访问特定聚合内部所有的实体类和值对象，应该包括创建，修改，删除聚合内部对象的方法。
工厂：Factories，工厂封装了创建复杂对象和聚合的逻辑，对客户端屏蔽创建的复杂性

上述DDD战术设计的模式标识了进行设计时的一些关键模式，但并非说是一定要严格使用和遵循的，也不是遵循了所有的战术设计模式就是符合领域驱动设计。因为，实践DDD关键不在于这种战术层面模式的落地，而是在于其宏观的领域驱动设计思想的遵循，比如统一语言、领域模型与代码间的一致、子域及上下文的拆分以及映射、领域模型与技术关注点的分离等等。另外，随着DDD的不断发展，一些新的构建模式已经涌现，老的构造模型不一定能符合团队研发的要求。