【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(通用语言体系)

简介: 【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(通用语言体系)

前言介绍

从前面的内容可以了解到领域建模需要软件专家和领域专家的合作,但由于基础交流的障碍,这种合作往往存在困难。软件专家会主要考虑类、方法、算法、模式等程序工件,他们会按照继承、多态、面向对象的编程等方式进行交流。然而,领域专家通常对这些概念不甚了解,他们只了解自己专业领域中的技能和知识。因此,在领域建模过程中,沟通交流是非常重要的,软件专家应该尽量减少使用专业术语、引入合适的例子帮助解释,而领域专家也应该尽可能地提供清晰的业务需求描述。只有通过双方的努力,才能够最终得到一个符合实际业务需求的模型。

降低沟通成本

在空中交通监控样例中,领域专家知道飞机、路线、海拔、经纬度等概念,并且能够判断飞机是否偏离了正常路线以及飞机的发射情况。然而,他们通常会用自己领域特有的术语进行讨论,使得对于一些非专业人士来说难以直接理解。因此,在与非专业人士沟通时,他们需要尽可能少地使用专业术语,或者使用通俗易懂的例子以帮助外行人理解。这样才能够达到更好的沟通交流效果。

问题:各自建立属于自己领域/层面的语言标准

领域专家和技术团队成员在交流中使用各自的行话和语言,这可能会导致沟通上的困难和误解。

解决方案1:专业术语转换为接地气的话术

为了在建立模型时克服交流方式不同的问题,需要进行频繁的沟通来交换想法,以便更好地理解模型以及其中涉及到的元素、连接方式、相关性等方面。

在这种交流中,需要尽可能地减少使用专业术语,并且使用通俗易懂的例子来帮助其他人理解模型中的各个要素。这种交流对于项目的成功非常关键,因为如果有人没有理解到某件事情,或者错误地理解成了其他事情,那么项目就有可能失败。因此,频繁的交流、耐心的解释以及清晰的表达都是非常重要的。

解决方案2:用简单的案例和背景信息进行描述

建议在交流时尽量使用通俗易懂的语言,尤其是对于不熟悉该领域的人来说。这可以通过提供更多的背景信息和例子来实现。另外,建议对于术语和专业领域的特定语言,在介绍时提供相应的注释或解释,使得其他人能够更好地理解。最后,也建议在设计讨论中加入一些可视化辅助工具,例如流程图和图表等,这些工具可以更加直观地展示设计和实现过程,有助于更加清晰地交流。

沟通语言的重要性

虽然代码是软件项目中最重要的产物之一,但实际上在日常讨论中使用的术语与实际代码中使用的术语往往不一样。即使是同一个人在交谈和书写时也需要使用不同的语言来表达自己的意思。为了深入了解领域,通常需要产生一种临时形式,但这种形式通常不会出现在代码或书面内容中。

沟通交流所出现的问题

在交流中,需要进行翻译才能让其他人理解相关概念。虽然开发人员可能尽力使用常人易懂的语言来解释设计模式,但并不一定每次都能成功。同时,领域专家可能会提出新的专有名词以表达其观念。然而,在这种痛苦的交流过程中,这种翻译工作并不能有效帮助知识的建构过程。

在模型讨论和定义中,我们需要使用一种共同的语言来交流。但是,这种语言应该是什么呢?是开发人员的语言,还是领域专家所使用的语言,还是介于两者之间的语言


通用语言的诞生

领域驱动设计的核心原则之一是使用基于模型的语言。模型作为软件满足领域共性的重要部分,非常适合作为构建通用语言的基础

使用模型作为语言的中心框架是领域驱动设计的一个重要原则。这个原则要求团队在所有的交流中使用相同的语言,包括代码和共享知识时使用的言语、文字和图形。这种语言被称为“通用语言(Ubiquitous Language)”,这是因为它在所有交流形式中都看上去一致的缘故。

通用语言

通用语言是建立设计团队良好工作前提的关键因素。在大规模项目中,设计可能需要数周乃至数月的时间才能达成目标。此过程中,团队成员可能会发现初始概念存在不正确或不适合的情况,或需要考虑并纳入总体设计的新设计元素。没有通用语言,这一切就不可能实现。

通过反映其他可选模型的表述方式,可以消除难点,并重构代码、重命名类、方法和模型以适应新的模型。使用普通词汇解决交谈中术语混乱的问题。构建一个这样的语言可以得到清晰的结果,模型与语言相互关联。对语言的变更将转化为对模型的变更。 领域专家反对使用笨拙或不适当的字眼或结构来传达对领域的理解。如果领域专家无法理解模型或语言中的某些内容,那么这就意味着存在某种错误。另一方面,开发人员应注意设计中存在二义性或不一致的内容。

创建通用语言

我们如何开始构建一种语言?以假想的软件开发人员和领域专家的关于空中交通监控项目的对话为例。

询问专家如何开始监控空中交通

  • 开发人员:询问专家如何开始监控空中交通。
  • 专家:建议从最基础的角度出发。所有的交通都是由飞机组成,每架飞机从一个出发点起飞,最后在一个目的地着陆。

询问是否在飞行时可以随意选择任何空中线路

  • 开发人员:认为飞机在飞行时可以随意选择任何空中线路,只要最终到达目的地。
  • 专家:解答称并不如此。驾驶员会收到规定的飞行路线,并需要尽可能地遵循这条路线。

询问是否在飞行时可以随意选择任何空中线路

  • 开发人员:他们将这条路线视为一条空中的三维线路。该线路可以使用笛卡尔坐标系列出一系列三维点,从而为飞行员提供更直观的参考。
  • 专家的观点与开发人员不同。专家认为,飞行路线实际上是预期的和纬度信息将会被用来确定它们的位置。

飞行高度以及方位的处理

开发人员称这些点为方位,并用一系列2D的点来描述飞行路线。出发点和终点也是方位,到达终点就像到达其他方位一样。然而,专家表示飞机在飞行计划中有规定的海拔高度,因此它不能按照自己的意愿选择高度。

沟通一下飞行计划信息

开发人员问专家:“飞行计划是什么意思?” 专家回答:“在起飞前,驾驶员会收到一份详细的飞行计划,其中包括有关本次飞行的所有信息,如飞行路线、巡航高度、巡航速度、飞机类型以及机组成员的信息等。”



我们可以通过将模型和代码之间、语言和代码之间进行映射来提高代码可读性,并完美实现模型。这种方式可以让整个项目受益。如果代码没有进行适当的设计,在模型变大或代码发生变化时,可能会导致意外结果。

相关文章
|
7月前
|
前端开发 测试技术 人机交互
DDD - 理论到落地从统一语言开始
DDD - 理论到落地从统一语言开始
443 0
|
前端开发 架构师 搜索推荐
COLA 4.0:直击应用架构本质的最佳实践
COLA 4.0:直击应用架构本质的最佳实践
2915 0
COLA 4.0:直击应用架构本质的最佳实践
|
4月前
|
设计模式 架构师 数据建模
架构师必备底层逻辑:设计与建模的技术深度探索
【8月更文挑战第13天】在软件开发的浩瀚星海中,架构师如同星辰指引,他们不仅规划着系统的蓝图,更在底层逻辑上精雕细琢,确保系统的稳健与高效。其中,“设计与建模”作为架构师的核心能力之一,是连接业务需求与技术实现的桥梁。本文将深入探讨架构师在设计与建模过程中的关键思维与实践方法,为工作学习中的技术同仁提供一份宝贵的干货分享。
57 3
|
7月前
|
敏捷开发 监控 架构师
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(构建领域知识)
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(构建领域知识)
196 0
|
7月前
|
敏捷开发 架构师 Java
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(基本概念篇)
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(基本概念篇)
188 0
|
7月前
|
存储 消息中间件 算法
深度思考:架构师必须掌握的五大类架构设计风格
数据流风格注重数据在组件间的流动,适合处理大量数据。调用返回风格则强调函数或方法的调用与返回,过程清晰明了。独立构件风格让每个构件独立运作,通过接口交互,提升灵活性和可重用性。虚拟机风格则模拟完整系统,实现资源的高效利用。
385 0
深度思考:架构师必须掌握的五大类架构设计风格
|
7月前
|
Python
继承概念深度解析:代码视角下的科普之旅
继承概念深度解析:代码视角下的科普之旅
32 0
|
消息中间件 前端开发 小程序
DDD实战之五:战略设计之上下文映射和系统分层架构(下)
DDD实战之五:战略设计之上下文映射和系统分层架构(下)
DDD实战之五:战略设计之上下文映射和系统分层架构(下)
|
存储 XML 缓存
「领域驱动设计」领域驱动的设计和开发最佳实践(下)
「领域驱动设计」领域驱动的设计和开发最佳实践
|
存储 XML 缓存
「领域驱动设计」领域驱动的设计和开发最佳实践
「领域驱动设计」领域驱动的设计和开发最佳实践

热门文章

最新文章