[领域驱动设计]-01-基本概念

2022-07-04 17:38 由 xingyuanyuan 发表于 #软件设计

领域驱动设计

领域驱动设计是关于软件开发时架构设计与建模的方法论，随着微服务架构的普及，领域驱动设计也随之被广泛使用。在本文中，将对领域驱动设计中的重要概念进行介绍。

界限上下文

在领域驱动设计中，首先需要根据客观对象的实际内容以及对业务的理解，划分出不同的领域。因此，引出了一个重要的概念：界限上下文。界限上下文（bounded context）指的是根据业务知识自然划分出的业务边界。比如，以书店为例，书店有两种基础的业务上下文，分别是仓储与销售。在不同的上下文中，书店这一客观实体将被以不同方式理解，所有与特定上下文相关的行为与逻辑都应该在这个上下文中被解决。当涉及到多个上下文交互的时候，通常会使用各个上下文中的门户对象进行交流（这一点有点类似于聚合中使用聚合根进行统一的管理与访问）
[Tips]：界限上下文实际上是一个解决方案侧的概念，其本质上是问题域到解决方案域的一种映射与抽象。领域是业务场景中对应的业务域，领域与子域可以划分为问题空间与解决方案空间，但一般主要指问题域。因此，界限上下文可能会穿插在几个子领域中。（参见《实现领域驱动设计》）

实体、值对象与聚合

界限上下文中最主要的元素就是领域模型。领域模型又由聚合、模块等基本元素组成。做一个浅显的类比，界限上下文好比一个城市的边界。划分完边界后，可能还会根据业务的具体需要划分出更细粒度的组织————聚合，聚合就好比在城市之中的各个街道与社区。当然，城市系统可以正常运作实际上离不开其中的人与物，类似于这一层级的概念，在领域驱动设计中我们将之称作实体、值对象。

实体

实体，拥有唯一标识符，经历状态变更后仍保持一致性。其重要特征是延续性和可标识性。比如在学生管理系统中，学生可以被设计为一个实体，每一个学生实体拥有唯一标识符。在不同的界限上下文中，名字相同的实体将会有不同的含义与侧重点, 比如在仓储的上下文中，我们关心书的尺寸、重量与类型，而在销售的上下文中，我们关心书的内容、外观、价格与评价。
相比于贫血模型的优势。所谓贫血模型指的是，模型仅对数据库中的表结构进行了简单映射，其余的逻辑大量充斥在其他的类中，需要依赖大量的Utils类去计算与之相关的业务逻辑。

贫血模型的缺点[1]

无法保护模型对象的完整性和一致性：对象的所有属性都是公开的，只能由调用方来维护模型的一致性，缺乏保障。

对象操作的可发现性极差：从对象的属性上难以直观的看出业务逻辑。什么时候可以被调用？赋值的边界是什么？举个例子，Long类型的值是否可以是0或者负数？

代码逻辑重复：如校验逻辑、计算逻辑等，很容易出现在多个服务的代码块里，这会提升后期维护的成本和bug出现的概率。

代码的健壮性差：比如一个数据模型的变化可能导致从上到下的所有代码的变更。

实体的合法性验证最好具有自封装性，即在setter或构造器中就进行自验证。对复杂实体进行验证时，可以采用延迟验证，即使用专门的验证类及其validate方法进行验证。

值对象

值对象，拥有一系列属性，没有唯一标识符。比如在学生管理系统中，家庭住址这一概念，可以由省、市、街道唯一编码，是一组静态的属性值，通常是不可变的。值对象具有相等性，即其所有的部分若相等，则整体是相等可替换的。值对象的所有方法都是无副作用的，不会破坏其不变性。

聚合与聚合根

聚合，可以认为聚合是拥有一系列相关的，在特定界限上下文中的实体与值对象的集合。在聚合中，我们通常使用聚合根来管理和访问聚合以及其中的其他成员。聚合根本质上也是一种实体，一般被称作为根实体。对于一个特定的界限上下文，可以由单个或多个聚合构成。

上下文映射图

上下文映射图讨论的是不同上下文之间的映射、协作关系。在Evans的书中，总结了如下几种基本的模式：

合作关系
共享关系
客户与供应关系
防腐层（是一种较为常见的方式）
发布语言

等等

Domain Primitive

Domain Primitive 是一个在特定领域里，拥有精准定义的、可自我验证的、拥有行为的 Value Object。（注：Domain Primitive的概念和命名来自于Dan Bergh Johnsson & Daniel Deogun的书 Secure by Design）
通常使用DP时，会遇到以下几种需求：

让隐性的概念显性化
让隐性的上下文显性化
封装多对象行为

常见的需要用到DP的场景：

有格式限制的String或Integer字段，如电话号码、地址、姓名、成绩等，因为一般含有校验逻辑，此时可以在DP中封装校验逻辑
复杂的数据结构的操作，如Map<String, List<Integer>>，可以使用DP来隐藏具体的细节。
具体细节可以参考这一篇博文

领域之间的交互

不同领域之间通过相互交互，完成特定的系统功能。一个上游领域在一个特定业务流程中，可能会与多个下游领域交互。比如购物车服务在后续需要与订单服务、仓储服务、邮件服务进行交互。但由于各个服务是以微服务形式存在的，如果使用上游服务去声明式（同步）地与下游服务进行交互，那么一旦当中某一个下游服务因故障无法正确执行，则会造成整个系统状态的不一致性。因此，使用异步的交互方式（发布-订阅）能避免这一问题，上游服务可以在消息中间件中下发特定的消息，让下游的服务异步进行消费。同时，这种异步的方式使上下游的服务相互解耦，当我们添加新的服务时，不需要改动无关的代码。

事件风暴

开发人员与业务人员一起分析领域，并提出相关的建模。在每次讨论中，只需要对特定的一个部分进行建模，而无需考虑全局的详尽细节。可以以类似于敏捷开发的形式，迭代循环。通常需要确定的是业务相关的事件，以及事件相关的活动。通常来说，我们可以先定义完整个事件流，然后每个事件流后补充对应的活动与规则。

参考

[1]Repository模式
 [2]DDD领域驱动设计-概述