阿里妹导读
一、构造块
构造块是指领域设计中最基本的一些元素。
构造块大图
1.1 分层架构
分层是常用的方法,不仅是领域驱动设计,计算机网络也会看到分层思想:网络的七层模型。分层的好处在于:可以集中精力关注每一层的功能职责,更好地分工协作。
分层的基本原则是:层中的任何元素都仅依赖于本层的其他元素或其下层的元素。下层如果不得已要调用上层的话,需要采用合适的模式,如观察者模式或者回调机制等。
常见分层如下:
用户界面层(或表示层):展示信息等。如:web 服务的 Contoller。
应用层:协调领域对象。如:支撑 Contoller 的 Service 服务。
领域层(或模型层):表达业务概念、业务状态信息、业务规则。
基础设施层:为上面各层提供通用的技术能力。如:数据库操作等。
1.2 关联
模型其实是真实世界模型的一个子集,不需要每个细节都反映出来,关联关系也是如此。
关联描述的是对象之间的联系,作者描述了3种减少关系复杂度的方法:
规定一个方向遍历:如,学校和校长是多对多的双向关系,但是如果可以考虑一个校长只在一个学校担任的职务的话,可以简化为学校到校长的1对多的关系。
添加一个限定符,以便有效地减少多重关联:如,在学校的某个特定时期,只有一位正校长。
消除不必要的关联:按需描述即可,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,并创建一个框架,这个框架要允许这些接口的各种不同实现被自由替换。