DDD重构-实体与限界上下文重构
DDD重构-实体与限界上下文重构
概述
DDD 方法需要不同类型的类元素，例如实体或值对象，并且几乎所有这些类元素都可以看作是常规的 Java 类。它们的总体结构是
Name: 类的唯一名称
Properties：属性
Methods: 控制变量的变化和添加行为
一般来说，DDD的实体、值对象和聚合根包含
把数据库表转换为Java类。包括类的名称和属性，还包括每个属性的类型，并符合DDD的模型数据库表和列的名称通常用带下划线分隔符的大写字母书写
类
用户需求决定一个类应该是实体、值对象、聚合根还是服务，它为给定的元素提供了或多或少的功能。实体和聚合根需要一个唯一的属性，该属性也是表中的主键列。稍后也可以更改此类型
然而，重新变回值对象或服务会消除唯一的标识。除此之外，聚合根与 Entity 非常相似。它可以被视为数据库中多对多关系的关联表。这里的情况也是为了使关系更容易。聚合根的另一部分是为服务提供方法。服务只包含没有任何属性的方法。服务和聚合根应该提供有界上下文中几乎所有的公共方法和不断变化的对象
添加新类: 如果决定从头创建一个新模型，也可能是这种情况。可以创建三种类型的新元素 实体、 值对象、 聚合根或 服务
属性
所有的属性都必须检查。数据库模型中的类型可能与用户期望的不同。NUMBER 就是这种类型的一个例子，因为它既可以是浮点数，也可以是整数。除了类型，名称也可以改变。此外，还可以添加其他属性或删除其中的一些属性
方法
为类声明简单的CRUD（创建、读取、更新、删除）方法，确保封装和对属性的访问
多数方法都应该在包中或受保护的可见性中，因为聚合根和服务应该向外部提供功能
从数据库中，只加载属性、属性与其他类之间的关系。这就是为什么用户可以声明元素的新方法，包括参数。
限界上下文
有元素都必须在至少一个有界的上下文中组织。这意味着通过避免对其他有界上下文元素的过多依赖来封装类元素。对于DDD，它有助于避免任何修改后不必要的副作用。首先，所有元素都可以放在相同的有限上下文中，但是用户应该考虑这种分离。可能是特定元素自有方法必须在多个有界上下文中使用，应通过在两个或多个有界上下文中复制同一元素来避免复制。因此，它们应该被放入一个共享的内核中
还应该可以将一个元素移动到另一个有界上下文，甚至可以复制该元素以在不同版本中使用。比如用户类。在“预约”有界上下文中，只需知道名称和电子邮件地址。但是，对于支付上下文中需要诸如信用卡号码之类的数据。如果在几乎所有有界上下文中都需要某些数据，那么这个类可能应该移动到共享内核。共享内核存储不同有界上下文的多个元素使用的所有类。它可以被看作是模型的核心部分。另一方面，核心类对更改的灵活性较差，因为它们可能在软件的其他几个地方使用。
关系
关系意味着属性使用关系图中另一个元素的类型。应该尽量减少应用程序之间的关系，并与服务一起使用。
除此之外，关于多样性还有两种关系。通常，它使用一对多关系，这意味着在另一个类中只使用一个元素，但有几个决定要使用哪个元素。另一种关系类型产生集合（例如列表、数组），其中多个元素存储在起始类的属性中。这是一种多对多的关系。可以使用多个元素，并且仍然可以决定将哪个元素添加到此集合中
通用语言
DDD 的另一个关键是在使用模型的每个项目团队之间创建一种统一的语言。然而，支持它的创建和开发是很难处理的。不过，每个元素都可以增加注释。它确保为每个元素保留关于通用语言的这些注释。
通常，通用语言已经在整个项目团队中确定，例如，为什么用这个名称调用这个类，或者为什么有这些属性。共享内核应该具有更高的优先级，因为这里的更改可能会导致比其他有界上下文更多的更改
验证
为了进行验证，必须考虑名称、类型和关系。
现界上下文的每个名称及其内的所有元素都必须是唯一的。这对于包名称来说更为重要，因为两个同名的包也被认为是相等的。如果名称重复，则必须用红色标记上下文名称或包名称，并使用工具提示文本告诉用户验证错误
必须检查所有类，包括实体、值对象、聚合根和服务。这意味着每个类的名称及其内容。名称在每个包中必须是唯一的，并且所有字符都必须有效。这应该符合Java中命名变量和类的规则。例如，在不使用关键字的情况下，只能使用字母数字字母，每个变量都必须以字母开头。可以用正则表达式检查它，并检查名称是否不等于关键字
还要检查关系的起点和终点。如果在多个访问非聚合根类的有界上下文中绘制关系线，则将被视为违规错误。应该使用服务。然而，这些关系只显示了属性的依赖关系，没有显示方法的关系。这就是为什么这里不会显示与服务的关系。
延伸阅读
-
DDD之领域及领域划分
-
一图了解领域驱动设计全过程
-
落地DDD的方法
-
CPU占用很高排查方案-CSDN博客
-
TOGAF业务架构-CSDN博客