领域驱动设计入门

 2021-10-25 23:34  阅读(79)
文章分类:领域驱动模型 文章标签:DDD领域驱动设计
©  原文作者:Jannik Wemp 原文地址:https://blog.jannikwempe.com/domain-driven-design-introduction

https://blog.jannikwempe.com/domain-driven-design-introduction作者 | Jannik Wemp
译者 | 平川 策划 | 万佳 领域驱动设计(DDD)是由Eric Evans发明的一个概念。他在2004年出版的《领域驱动设计》一书(即”大蓝皮书“)中探讨了这个概念。我将概要地介绍下DDD的方方面面。本文将探讨DDD“为什么?”和“是什么?”。在这里,我不会深入探讨具体的主题。不过,我会说明重要术语的定义。

领域驱动设计(DDD)是由Eric Evans发明的一个概念。他在2004年出版的《领域驱动设计》一书(即”大蓝皮书“)中探讨了这个概念。

那么在DDD上下文中,领域是什么?

领域是知识、影响或活动的范围。用户应用程序的主题域即软件的领域。

我将概要地介绍下DDD的方方面面。本文将探讨DDD“为什么?”和“是什么?”。在这里,我不会深入探讨具体的主题。不过,我会说明重要术语的定义,就像上面的“领域”。你会发现,共享词汇也是DDD本身的一部分。

首先,你要问自己,这些概念是否仍然有效?

1DDD的意义

DDD不是一种特定的技术,它是一个概念。许多现代概念都直接使用DDD。下面这段话出自Sam Newman《微服务设计》一书的第一页。

Eric Evans的《领域驱动设计》一书帮助我们理解了用代码呈现真实世界的重要性,并且告诉我们如何更好地进行系统建模。

此外,IBM Garage事件驱动参考架构有一章专门介绍DDD方法。

至于DDD的意义,可以说时至今日,它确实非常有效。说完了最新的情况,让我们继续探讨 “为什么?”和 ”是什么?“

2为什么会有DDD

DDD不是一种特定的技术,它是一个概念。许多现代概念都直接使用DDD。下面这段话出自Sam Newman《微服务设计》一书的第一页。

为什么会需要像DDD这样的东西?Eric Evans在其著作的副标题中提供了一条很好的线索:

攻克软件核心的复杂性

通常情况下,软件项目的主要复杂性在于领域本身。你无法改变领域的复杂性。你可以试试告诉你的银行客户,你将专注于支付,而放弃贷款业务,因为它太复杂了。

此外,我们不是为了开发软件而开发软件。我们是为了解决问题以及做些改进:

软件的核心是为用户解决领域相关问题的能力。其他所有功能,虽然也很重要,但都是服务于这一基本目的。

3DDD是什么

微服务的关键特征之一就是其松散的耦合,而这一特征则允许它们单独进行开发、部署、访问控制和扩展。

那么DDD是什么?DDD无法用一两个句子定义。它是一种开发解决多个问题的复杂软件的方法:

  1. 关注领域的核心复杂性和机会;
  2. 领域专家和软件专家合作探索模型;
  3. 在有界上下文中说一种通用语言。

(注意正文中的绿色词汇。这些是DDD中特有的术语,我会给它们下个定义,就像给领域下定义一样。)

这三点是对DDD非常高度的概括。接下来,我会一个一个地介绍。

关注领域关注领域的核心复杂性和机会。

这一点我就不过多介绍了。根本的东西我在上面“为什么”这一部分里都已经说明了。软件是没有自我目的的。

不要把这点和“关注业务”弄混了。核心复杂性和机会与我们所说的“业务”并不是一回事。想一下Twitter。在它的功能中,互相关注等功能并非主要的复杂性所在。主要的复杂性更多的可能还是来自扩展平台。

探索模型

领域专家和软件专家合作探究模型。

模型是应对上述复杂性的一种方法。但首先,我们要弄清楚模型是什么?

在DDD上下文中,模型是什么?

描述领域部分方面的一系列抽象,可以用于解决与该领域相关的问题。

另一种来自Eric Evans的描述:

模型是一种简化。它是对现实的解释,它将有助于解决现有问题的重要方面抽象出来,而忽略掉不相干的细节。

我觉得有必要明确下它不是什么:它不是一张图(因此也不是实体关系图(ERD),虽然DDD也使用实体这个术语)。图只是帮我们就模型进行交流。在DDD的语境下,你会看到许多图。没有什么唯一的建模专用语言。最常用的是一些类似UML的图,或者仅仅是一幅手绘草图。重要的不是图,而是图背后的概念。

选择“探索(explore)”而不是像“写下”这样的词,是有其用意的。要获得一个模型,需要经过一个迭代过程。建模这样的事不可能一次性完成。领域里会有新的洞察,新的或变化的问题,诸如此类。这是一个持续探索的过程。

模型举例

考虑下平常的世界地图(有点像一张图)。标准世界地图显示的是墨卡托投影。人们都知道,地图不是为了说明不同国家的大小或其他类似的东西。它是专门为海上航行而制作的。在地图上的两点之间画一条线,借助指南针就可以知道如何航行了。

下图显示了地图背后的东西,即具体的模型:

202110252334157331.png

Eric Evans在2019年的会议演讲中使用的这个例子很不错。它说明了模型与当前的问题直接相关。


有个模型并不能让你获得任何优势。优势并非因为有模型。优势是你因为有一个模型,可以非常好的匹配你正在设法解决的一组特定问题。

对比开头的句子,这里少了一个非常重要的部分:“领域专家和软件专家合作“。模型必须合作探索。不是单由领域专家创建模型,也不是单由开发人员拿ERD当模型叫卖。Eric Evans将合作探索模型的过程称为“知识研磨(Knowledge Crunching)”。

在本节的最后,让我们看一个非常重要的观点。Eric Evans的下面两段话是这一观点的最佳表述。

本书的主旨是,实施、设计和团队沟通应该在一个模型里。不同的用途采用不同的模型会存在隐患。

如果编写代码的人觉得自己不负责模型,或者不理解如何在应用程序开发中运用模型,那么模型就和软件没关系了。如果开发人员没有意识到修改代码会改变模型,那么他们的重构会弱化而非强化模型。

本节要点:代码和模型直接相关。

说一种通用语言在有界上下文中说一种通用语言。在DDD上下文中,通用语言指的是什么?一种围绕领域模型构造的语言,供所有团队在有界上下文中使用,将团队的所有活动与软件联系起来。还有一个有必要定义的术语是:有界上下文。上下文:单词或语句在其中出现的、可以决定其意思的环境。模型的语句只能在上下文中进行理解。有界上下文:对边界(通常是一个子系统或特定团队的工作)的描述,特定模型在其中定义,同时也是模型的适用范围。*(至此,我们已经介绍了本文所需的所有定义。)值得注意的是,“通用”语言并不是适用于整个系统的通用。它主要是用于代码、口语、图表等方面。这也是为什么要说“在有界上下文内”。该语言将在你明确定义的边界内适用。它定义的不是跨边界(如整个公司)的术语。举例来说,这会让营销或仓储上下文的文章看起来大相径庭,甚至是在仓储上下文的不同部分也是如此。(你可能已经注意到,我在每个定义里都加了“在DDD上下文中“。这就是原因。)*用我自己的话来说:通用语言是特定领域中与模型直接关联的公共语言,在定义好的边界内可以随处使用。“与模型直接关联”是说语言的变化也会直接关系到模型的变化。事实上,模型应该使用领域专家已经在使用的术语创建。[...] 语言的更改将被看成是领域模型的更改,团队得相应地更新类图,重命名代码中的类和方法[...]模型是语言的支柱。[...] 在图表、写作,特别是口语中使用同样的语言。现在,我们已经清楚了术语的含义,但为什么这很重要呢?关于这一点,书中有这么一段话:在一个没有公共语言的项目里,开发人员得给领域专家做翻译。领域专家要在开发人员之间做翻译,同时还要给其他领域专家做翻译。甚至开发人员之间也需要翻译。你一定遇到过这样的情况,开发人员不知道领域专家在说什么,或者更糟糕,你觉得自己知道,但他/她说的其实是其他东西。反之亦然。对于使用的专门术语,要使团队养成询问其含义的习惯。团队要在所有的沟通活动中不断地练习使用通用语言。如果领域专家正在谈论的、属于某个特定领域的概念在模型中没有体现,那么这个模型可能不完善。通用语言会使得代码与实际的领域更贴合。这不仅是说代码可以体现实际的领域,而且还有许多其他方面的好处。考虑下代码的可维护性。如果后续有开发人员回过头来查看代码,其中使用了领域术语。确实,领域专家了解用到的术语,但那并不是开发人员定义的类名。4更多概念

上面的内容是对DDD一个高度概括的介绍。无疑,它还有许多其他的概念。

202110252334168382.png

上图是DDD中不同概念的一个总览。如你所见,我只介绍了其中的一小部分。我接下来会写一篇文章介绍实体、值对象和聚合的概念。但本文足以帮你了解DDD是干什么的。

5总结

DDD仍然是你工具箱中的一个重要概念。它已经影响了许多其他的领域可以看下JPA规范的JavaDoc:https://github.com/spring-projects/spring-data-jpa/blob/main/src/main/java/org/springframework/data/jpa/domain/Specification.java

并且还会继续影响它们。

解决领域问题是软件开发的全部内容。那是我们需要面对的复杂性。但是,运用DDD可以让我们的工作变得更轻松。

希望您喜欢这篇文章。欢迎反馈。您可以在Twitter或LinkedIn上联系我:https://twitter.com/JannikWempehttps://www.linkedin.com/in/jannik-wempe/

6
相关资料

当然,最主要的资料是《领域驱动设计》一书:https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/

Eric Evans在网上免费提供的领域设计驱动参考:https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf。

IBM Garage事件驱动参考架构也包含有关DDD的信息:https://ibm-cloud-architecture.github.io/refarch-eda/methodology/domain-driven-design

我很喜欢Eric Evans在DDD欧洲2019大会上的这个演讲:https://youtu.be/pMuiVlnGqjk

当然,YouTube上还有其他许多不错的演讲。

版权归原创作者所有,任何形式转载请联系作者; Java 技术驿站 >> 领域驱动设计入门

相关推荐