5分钟迅速掌握领域驱动设计的40个关键概念

科技   2025-01-15 18:00   浙江  

阿里妹导读


本文对《领域驱动设计-软件复杂性应对之道》一书进行高度凝练,梳理了领域驱动设计的架构图、基本要素和重要概念。从细节入手,以小见大,你想知道的定义,这里都有。

一、构造块

构造块是指领域设计中最基本的一些元素。

构造块大图

 1.1 分层架构 

分层是常用的方法,不仅是领域驱动设计,计算机网络也会看到分层思想:网络的七层模型。分层的好处在于:可以集中精力关注每一层的功能职责,更好地分工协作。

分层的基本原则是:层中的任何元素都仅依赖于本层的其他元素或其下层的元素。下层如果不得已要调用上层的话,需要采用合适的模式,如观察者模式或者回调机制等。

常见分层如下:

  1. 用户界面层(或表示层):展示信息等。如:web 服务的 Contoller。

  2. 应用层:协调领域对象。如:支撑 Contoller 的 Service 服务。

  3. 领域层(或模型层):表达业务概念、业务状态信息、业务规则。

  4. 基础设施层:为上面各层提供通用的技术能力。如:数据库操作等。


 1.2 关联 

模型其实是真实世界模型的一个子集,不需要每个细节都反映出来,关联关系也是如此。

关联描述的是对象之间的联系,作者描述了3种减少关系复杂度的方法:

  1. 规定一个方向遍历:如,学校和校长是多对多的双向关系,但是如果可以考虑一个校长只在一个学校担任的职务的话,可以简化为学校到校长的1对多的关系。

  2. 添加一个限定符,以便有效地减少多重关联:如,在学校的某个特定时期,只有一位正校长。

  3. 消除不必要的关联:按需描述即可,less is more。


依赖关系示意

 1.3 entity 

实体 entity 的定义:主要由标识定义的对象被称做entity,特点是在整个生命中具有连续性。

简单理解为领域层中带有意义ID的对象,如:订单信息(含订单ID)。

 1.4 value object 

值对象 value object 的定义:用于描述领域的某个方面而本身没有概念标识的对象称为 value object。

简单理解为对象属性决定差异的个体,如:颜色RGB对象,只要rgb值一致,那么其实是一种颜色,并不关心对象的本身到底是哪个实例。

这类对象特点:

  • 经常作为参数在对象之间传递消息,常常是临时对象。

  • 设计选择:复制、共享或保持value object不变。

  • 为性能优化提供了更多选择:可缓存、可共享等。


 1.5 service 

领域层中服务 service 的特征:

  • 与领域概念相关的操作不是 entity 或 value object 的一个自然组成部分。

  • 接口是根据领域模型的其他元素定义的。

  • 操作是无状态的。

简单理解为领域层中一些需要协调多个对象的无状态函数。可以暴露领域中的一些功能。

值得注意的是:

  • service不只在领域层使用,根据职责,service也会分到各层中。

  • 可以控制领域层中接口的粒度。


 1.6 aggregate 

聚合 aggregate 是一组相关对象的组合,有一个根(root)和一个边界(boundary)。外部对象只能引用根,而边界之间的内部对象之间则可以相互引用。

聚合根示意图

 1.7 factory 

工厂 factory 负责复杂对象和aggreate的创建,是领域设计的一部分。

 1.8 repository 

存储库 repository 为那些需要直接访问的对象提供数据访问能力,封装底层存储逻辑。

 1.9 specifiction 

声明 specifiction 是为特殊目的创建了谓词形式的 VALUE OBJECT,是一个谓词,可以用来确定对象是否满足某些标准。

场景:某些业务规则不适合作为Entity 或 VALUE OBJECT 的职责。

二、柔性设计

柔性设计(supple design)运用深层模型所蕴含的潜力来开发出清晰、灵活且健壮的实现,并得到预期的效果。

柔性设计关键要素

 2.1 intention-revealing interfaces 

释意接口 intention-revealing interfaces:在命名类和操作时要描述它们的效果和目的。

 2.2 side-effect-free function 

无副作用函数 side-effect-free function:尽可能把程序的逻辑放到函数中,函数不产生明显的副作用,把命令(引起明显状态改变的方法)隔离出来。


 2.3 assertion 

断言 assertion:对程序某个时刻正确状态的声明,在编程中编写 assertion 或者单元测试。

 2.4 conceptual contour 

概念轮廓 conceptual contour:领域本身的一致性,把设计元素分解为内聚的单元。

 2.5 standalone class 

孤立的类 standalone class:无需引用任何其他对象(系统的基本类和基础库除外)就能够理解和测试的类。把无关对象提取到对象之外,保持低耦合。

 2.6 closure of operation 

闭合操作 closure of operation:闭合操作提供了一个高层接口,同时又不会引入对其他概念的任何依赖。在适当的情况下,可以定义操作的返回类型与参数类型相同。

三、战略设计

战略设计(strategic design):一种针对系统整体的建设和设计决策。

战略类型

 3.1 bounded context 

限界上下文 bounded context:特定模型的界限应用。限界上下文使团队知道什么必须保持一致,什么必须独立开发。

 3.2 continuous integration 

持续集成 continuous integration:把工作足够频繁地合并到一起,并使它们保持一致。

 3.3 context map 

上下文图 context map :项目所涉及的界限上下文以及它们与模型之间的关系的一种表示。描述模型之间的联系点,明确所有通信需要的转换,并突出任何共享的内容。

上下文映射示意

 3.4 shared kernel 

共享内核 shared kernel :通常是共享核心领域或者是一组通用子领域。

共享内核

 3.5 customer/supplier 

客户/供应商关系 customer/supplier:上下游关系。不同客户需要协商来平衡,上游团队需要有自动测试套件。

客户/供应商关系

 3.6 conformist 

跟随者模式 conformist:单方面跟随模式。上游的设计质量较好,容易兼容,可以采用严格遵循上游团队的模型。

跟随者模式

 3.7 anticorruption layer 

防腐层 anticorruption layer:防腐层、隔离层,使用 facade or adapter 等模式。可以减少其它系统变动对本系统的影响。

防腐层

 3.8 separate way 

各行其道 separate way:声明一个与其它上下文毫无关联的 bounded context,使开发人员能够在这个小范围内找到简单、专用的解决方案。

各行其道

 3.9 open host service 

开放主机服务 open host service:开放子系统供其他系统访问。

开放主机服务

 3.10 published language 

共享语言 published language:把一个良好文档化、能够表达领域信息的共享语言作为公共的通信媒介,必要时在其它信息与该语言之间进行转换。

四、精炼

精炼(distillation):是把一堆混杂在一起的组件分开的过程,从中提取出最重要的内容,使得它更有价值。

精炼要素

 4.1 core domain 

核心领域 core domain:模型中最关键的部分,是程序的标志性部分,也是应用程序的核心诉求。

 4.2 generic subdomain 

通用子领域 generic subdomain:识别出对项目意图无关的内聚子领域,提取通用模型,并分离出来。

 4.3 domain vision statement 

领域愿景说明 domain vision statement:类似愿景说明文档,关注领域模型的本质,以及如何为企业带来价值。

 4.4 highlight core 

突出核心 highlight core:编写简洁文档描述 core domain 以及核心元素之间的主要交互过程,并把 core domain 标记出来。

 4.5 cohesive mechanism 

内聚机制 cohesive mechanism:把内聚的部分分离到一个单独的轻量级框架汇中, 并用释意接口暴露框架功能,从而使得领域元素关注“做什么”,“怎么做”转移给了框架。

 4.6 segregated core 

分离的核心 segregated core:把核心概念从支持性元素中分离出来,并增强核心的内聚性。把通用元素、支持性元素提取到其它对象中。

 4.7 abstract core 

抽象核心 abstract core:识别模型中最基本的概念(能表达出主要组件的大部分交互),并分离到抽象模型中(类、抽象类或接口)。抽象模型放在自己的模块中,实现类留在子领域定义的模块中。可以减少模块间依赖的复杂性。

抽象核心


五、大型结构

大型结构(large-scale structure):一组高层的概念、规则,它为整个系统建立了一种设计模式,能够从更大的角度来讨论和理解系统。

大型结构要素

 5.1 evolving order 

演变有序 evolving order:让概念上的大型结构随着应用程序一起演变,甚至可以变成一种完全不同的结构风格。

演化示意

 5.2 system metaphor 

系统隐喻 system metaphor:当系统的一个具体类比正好符合团队成员对系统的想象,并且能够引导他们向着一个有用的方向进行思考时,就应该把这个类比用作一种大型结构。例如:用真实大楼的防火墙来类比网络的防火墙。

防火墙类比

 5.3 responsibility layer 

职责分层 responsibility layer:在具有自然层次的模型中,可以围绕主要职责进行概念上的分层,这样可以结合使用”分层“和”职责驱动的设计“这两个有力的原则。

地球的“分层”

 5.4 knowledge level 

知识级别 knowledge level:是一组描述了另一组对象应该有哪些行为的对象。当我们需要让用户对模型的一部分有所控制,而模型又必须满足更大的一组规则情况时,可以利用这个模式来处理。可以通过类型的知识,去选择不同的策略。

知识级别

 5.5 pluggable component framework 

可插入式组件框架 pluggable component framework:从接口和交互中提炼出一个抽象核心 abstract core,并创建一个框架,这个框架要允许这些接口的各种不同实现被自由替换。

阿里云开发者
阿里巴巴官方技术号,关于阿里的技术创新均呈现于此。
 最新文章