Page 32 - 《软件学报》2021年第9期

2656 Journal of Software 软件学报 Vol.32, No.9, September 2021

微服务粒度.这一方法已被软件开发社区广泛接受 [51] .然而对于限界上下文本身的粒度,DDD 并没有提供任何
有助于实现高内聚、低耦合(C2)的指导方法.近期的一项相关研究 [59] 证实了这一挑战,该工作宣称:使用限界上
下文对软件系统进行拆分是非常困难的,因为不同业务功能之间的界限通常并不明显.
将一个领域拆分为多个子域之后,应首先识别出系统中最具决定性的子域,即核心域,并侧重对核心域的投
[4]
入,以实现收益最大化 .但在实际中,对开发人员而言,识别系统的核心域往往非常困难(C3),尤其是在开发大型
系统时.此外,基础研究 [52] 还发现,在实践中可能会同时存在多个核心域,因此进一步加剧了这一挑战.
在每个限界上下文内应用战术设计模式主要面临两个挑战:其一,确定聚合的粒度非常困难(C4),这需要在
执行单个事务的成本和强一致性两者之间取得平衡 [58] ;其二,使用分层架构(layered architecture)将领域模型与
其他模块进行对应时,DDDP 中并未对领域层之外的其他层,如用户界面层、应用程序层和基础设施层等,提供
[1]
任何相关规范(C5) .本质上讲,领域驱动设计强调使用领域模型来展示领域的功能视图,但并没有考虑其他方
面 [30] .然而,这种对领域层之外规范的缺失,将会为实践者带来一定的困扰.
[1]
在模型中表达领域知识时,Evans 强调可以利用各种媒介进行沟通(不仅是 UML [31] )来最大化模型表达的
效率.但这就带来了另一项挑战,即,领域驱动设计缺乏对模型的形式化表达的支持(C6).文献[44]指出:DDD 的
定义不仅缺少形式化基础,还在某些情况下具有不同的表达方式.在应用微服务架构构建应用程序时,领域模型
将分散在不同团队中,因此具有相同语义的领域对象可能会在不同团队中独立演变,从而变得完全不同.这样一
来,很可能使得不同团队对相同的领域概念产生不同的理解 [47] .
在基础研究文献中还提到了其他的一些挑战,如基础研究 [46] 所描述的,领域模型的建模过程需要领域专家
的参与,但却无法保证领域专家能够理解建模过程中使用的全部技术(C7),这对于通用语言的实践造成了一定
困难.此外,当前的建模工具还不能完全适用于领域驱动设计(C8).最后一点,虽然 DDD 提供了多种模式,但是领
域模型的复杂度依然会影响模型本身的可理解性(C9).
• 缓解方法
为了确定限界上下文的合理粒度(C2),多个研究文献给出了相关建议.首先,文献[30,44]认为,应该考虑团队
的组织结构.其次,文献[41]建议找到职责的边界,并将其作为该领域的业务功能.文献[49]建议通过分析用例的
工作流将相关功能聚集在一起,并将其划分为不同的领域,也就是限界上下文;此外,通过将领域专家和开发人
员召集在一起来讨论业务领域的事件风暴 [60] ,也是一种行之有效的重要手段.通常而言,限界上下文往往需要经
过多次迭代才能够最终确定,根据文献[42]的经验,比较来自于不同团队的领域模型,有利于使领域边界更清晰.
为了应对微服务场景中的 C5,也就是领域驱动设计在其他层中没有提供任何规范这一挑战,需要添加其他
工件来弥补规范的缺失 [30] .根据 Fairbanks [61] 的建议,在决定向系统中增加新的工件时,需要仔细考虑项目中存
在的风险.例如:当使用 DDD 构建基于微服务的 Web 应用程序时,文献[30]根据用户体验设计的指导原则来定义
用户界面和交互,根据行为驱动开发(behavior-driven development)来确定应用层的需求,并使用 Spring 框架搭建
基础设施层.
为了使建模语言更加形式化(C6),基于在领域驱动设计中应用 UML 元素情况的调研,文献[44]定义了一种
用于建模的 UML 配置文件(profile),并充分考虑到了各元素的语法和语义.应用这种 UML 配置文件的案例表
明,其能够将基于这种配置建模的领域模型映射到微服务中.文献[48]的研究工作进一步验证了这种 UML 配置
文件的有效性.除此之外,本体论是一种在特定领域中描述语义的方法,其能够对系统结构进行形式化建模,比
如实体和关系等 [62] .基于本体论,基础研究 [47] 提出了一种表达领域模型语义及关系的元模型,以此来确保整个
团队对分布式领域驱动微服务设计中的相关领域概念具有相同的理解.
对于建模工具(C8)而言,文献[44]在 Eclipse 和 Papyrus 建模环境的基础上实现了 UML 配置文件;文献[56]
在 Eclipse 平台上开发了 Elihu 项目,能够对于领域对象相关的应用功能进行建模,而无需考虑基础设施方面的
问题.此外,文献[48]建议使用另一个基于 Eclipse 的工具——AjiL 来实现微服务的图形化建模.AjiL 能够通过建
模得到初步的领域模型,并通过代码生成器将模型转化为微服务的具体实现.
[9]
对于模型复杂度(C9)而言,概念架构视图 被引入并用于将模型拆分为多个领域视图.这样一来,建模者能