其他分享
首页 > 其他分享> > 不容错过!什么是领域驱动设计?为什么落地这么难?

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

作者:互联网

引言

领域驱动设计并不是新的架构设计理论,从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提供的模型驱动设计的构造要素以及要素间的关系如下图所示:

 


 

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

领域驱动设计为什么落地这么难?

需要鲁棒的领域知识,依靠项目中领域专家的支持

强调不断迭代和持续集成,对缺乏迭代经验而偏重于瀑布模型的团队可能导致障碍

领域驱动设计实践依赖不断迭代和持续集成来构建高可扩展的项目,但是这种基于迭代和持续集成的时间,在某些团队中落地可能会存在阻碍,特别是如果过去经验是建立在僵化的开发模型上,比如瀑布模型。

不适合偏向技术型的应用

领域驱动设计适合于具有非常高领域复杂性(业务逻辑复杂)的应用,但不适用于领域复杂性很低但技术复杂性很高的领域。DDD着重强调需要领域专家以便构造出项目依赖的统一语言和领域模型,但是如果项目的技术复杂性很高,领域能否理解是一种挑战。当全体团队成员没有完全理解技术需求或限制时可能会导致问题

团队过于重视战术设计,导致实践准线和原则的偏离

团队对领域驱动设计的认知不够,精力没有聚焦在问题域拆分、统一语言、模型与技术关注点分离等核心原则上,而是一开始便从实现的角度触发,过度强调战术设计模式的落地,从而陷入无尽的技术细节之中

标签:落地,模型,领域专家,领域,容错过,设计,驱动,DDD
来源: https://www.cnblogs.com/Jcloud/p/16623237.html