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

贾子甲 等:领域驱动设计模式的收益与挑战:系统综述 2655

Table 9 Challenges of applying DDD patterns (Continued)
表 9 应用 DDDP 所需要面对的挑战(续)
ID 描述 计数 相关模式及研究文献 缓解方法
领域设计
M9:实现了用于建模的 UML 配置 [44]
M10:Elihu 无需对基础结构进行建模
[46]
C8 缺少合适的建模工具 1 LA [56]
即可实现业务功能建模
M11:支持图形建模的 AjiL [48]
领域复杂性使领域 MultiPattern(UL, M12:使用领域视图将模型分
C9 1 [30] [30]
模型难以理解 BC,CM,CD) 解为几个视图
领域模型实现
实现防腐层是不仅 [41,53]
C10 2 AL /
成本高,而且复杂
为服务的实现 [43]
C11 1 Service /
留下了大量复杂性
缺少对后续 BC [48] ,Service [44] , M13:使用建模约定来解决领域
C12 3 [46] [48]
实现的规范 LA 模型缺乏规范的问题
C13 领域模型未覆盖基础组件的需求 1 Service [48] M14:使用中间模型表示技术特性 [48]
缺少对模型到代码的 MultiPattern
C14 1 [44] /
自动化转换的支持 (BC,CM)
普适性活动
不同的涉众很难 [37] M15:专注于信息架构定义
C15 1 UL [37]
对领域概念达成共识 一致的术语
不同团队之间的领域 MultiPattern [48]
C16 1 [48] M16:明确模型的使用权限
模型访问和变更管理困难 (Service,BC)
缺少应用 DDD 的软件 MultiPatter M17:基于领域驱动设计的
C17 1 [30] [30]
开发过程的系统描述 (LA,Service) 软件开发活动概述
注:表格使用简写表示相关模式,其中 CM=“上下文映射”,RL=“职责分层”,OHS=“开放主机服务”,AL=“防腐层”,BC=“限界上下
文”,LA=“分层架构”,CD=“核心域”,UL=“通用语言”.MultiPattern 代表这种挑战与多种 DDDP 的综合作用相关
3.4.1 领域分析
在领域分析部分,本文发现了一种应用 DDDP 的挑战(C1),但是并没有在研究文献中找到能够缓解该挑战
的方法,因此在本部分的缓解方法中,本文根据经验总结出了两条应对建议.
• 挑战
领域驱动设计及模式致力于帮助开发组织深入理解软件的业务领域,以便在系统开发中充分发挥创造
力 [39] .为了更加深入地了解相关领域,无论是形成统一语言还是确定限界上下文和核心域,都强调领域专家与开
发人员之间的紧密协作.然而,让领域专家参与领域驱动设计实践并非易事(C1),这成为了阻碍 DDDP 成功应用
的一个主要障碍,特别是在所开发的软件系统非常复杂,需要不同领域的多个领域专家共同参与的情况下.
[4]
Vernon 也认同了这一观点,他认为:让领域专家参与软件开发过程,一直以来都十分困难.
• 缓解方法
在本研究所搜集的基础研究文献中,并没有针对领域分析阶段所遇到的 C1 提出任何解决方案.显然,C1 更
[4]
像是一个组织问题,而不是技术问题.结合 Vernon 的观点,我们为应对 C1 提供了两条建议:① 如果软件开发组
织决定应用领域驱动设计,那么就应该充分认识领域专家的重要性;② 领域专家指的不是一个职位,而指的是
[4]
非常了解业务线的人,因此,领域专家可能是销售人员,也可能是产品设计师 .
3.4.2 领域设计
在领域设计部分,本文发现了 8 种应用 DDDP 所带来的挑战(即 C2~C9),并且对于其中除了 C3,C4 和 C7 之
外的 5 项挑战都发现了一些对应的缓解方法(M1~M12).
• 挑战
通过引入限界上下文模式,可以将复杂软件系统拆分为不同部分,拆分后的每个部分都可以独立建立具有
[8]
清晰边界的领域模型.正如 Newman 所建议的:借助限界上下文将相关业务功能组合为业务能力,以此来确定