Page 28 - 《软件学报》2021年第9期
P. 28

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

             [5]
         Tune 的发现基本一致,即,开发人员更容易注意到领域驱动设计的战术设计模式.总体而言,目前只有 31.1%
         (14/45)的 DDDP 在基础研究中得到了探讨,这也表明了当前学术界对 DDDP 的研究存在不足.
                                 Table 7    Distribution of DDD patterns in literatures
                                      表 7   研究文献中 DDDP 的分布情况
                        DDDP                   描述                    相关文献          计数
                                                  通用语言
                       通用语言         一种围绕领域模型构建的共享语言,
                    (ubiquitous language)  主要用于促进团队协作工作中的沟通.        [30],[34−47]    15
                                                  战略设计
                                    复杂的软件项目中往往存在多个领域
                       限界上下文        模型,而限界上下文通过显式的模型             [30],[34],[39],[41,42],   11
                     (bounded context)                              [44], [47−51]
                                     边界来避免与其他模型产生模糊.
                       上下文映射             软件项目中涉及的限界
                      (context map)    上下文及其之间关系的表示.               [30],[41],[52,53]  4
                       分层架构         将复杂的软件系统划分成多层,并将
                    (layered architecture)  领域模型与其他关注点分离开来.    [30],[35],[38],[46],[52],[54],  6
                       职责分层         用于将模型重构为层次结构,其中每个
                    (responsibility layer)  领域对象的职责与其层次完全对应.        [39],[52,53]     3
                        防腐层              封装了两个限界上下文
                    (anticorruption layer)  之间的信息转换的隔离层.         [30],[49],[52,53],[55]  5
                        核心域          使应用区别于其他应用,并且也是
                      (core domain)   领域模型中最值得开发的部分.             [30],[35],[39],[52,53]  5
                                                  战术设计
                         实体            用于建模在整个生命周期中              [30],[34−37],[39],[41],   13
                        (entity)     唯一且可以持续变化的领域对象.            [43],[44],[47,48],[54],[56]
                        值对象             用于建模某些不具有唯一              [30],[34−37],[39],[41],   12
                      (value object)    标识的特征的领域对象.               [43,44],[47,48],[56]
                         聚合           用于将一组实体和值对象封装              [30],[34−37],[39],[41],   13
                       (aggregate)   起来,使其作为一个整体进行处理.           [42],[44],[47,48],[56,57]
                        资源库                为领域对象封装               [34−37],[39],[41],[44],   12
                       (repository)     数据库访问的概念框架.                [48],[52],[55−57]
                         服务            用于对充当模型接口的操作              [30],[34],[36,37],[39],   10
                        (service)      建模,并且不封装状态信息.               [43,44],[47,48],[56]
                      工厂(factory)   用于封装领域对象的复杂创建逻辑.              [30],[34],[37],[39]  4
                       领域事件              用于将领域中的活动                  [30],[34],[58]   3
                      (domain event)    信息建模为一系列事件.
                                                                      [4]
             作为一种模式语言,DDD 由一组相互关联的模式组成(即 DDDP).Vernon 指出:如果在实践中忽略通用语
         言和 DDD 战略设计,而仅仅使用部分战术设计模式,就可能导致领域概念之间的紧密耦合,这样的问题被称为
         “DDD-Lite 陷阱”.本研究发现:在研究集合中,仅有文献[30,41,42]明确地应用了通用语言、战略设计模式和战术
         设计模式.有 2 项研究可能落入了 DDD-Lite 陷阱,因为它们只展示了战术模型,而没有提出任何与战略层面实践
         相关的观点.比如文献[35]在文章中论述了他们如何演进通用语言、战术领域模型以及持久化策略等实现细节,
         而并没提及战略设计.与此同时,5 篇研究文献在研究中只采用了战略设计,而没有关注战术设计.具体而言,这些
         研究专注于企业架构层面,主要分析如何利用战略模式(如限界上下文和上下文映射等)来组织具有多个领域模
         型的大规模结构.此外,基础研究[40]较为特别,它既没有论述战略设计,也没有论述战术设计,而是分析了如何通
         过映射具有相似语义的领域概念,将两种不同的战术领域模型集成到一起.

         3.3   应用DDDP所带来的收益(RQ2)
             为了便于读者理解,本文以表格形式展现了将 DDDP 应用到 DDD 活动中的收益与挑战.表 8 展示了应用
         DDDP 所带来的收益在领域分析、领域模型实现以及普适性活动中的体现情况,并展示了相关模式和研究文献
         的证据覆盖范围.除领域分析之外,本研究在 DDD 活动的各个阶段均发现了应用 DDDP 所带来的收益.
   23   24   25   26   27   28   29   30   31   32   33