DDD重构-实体与限界上下文重构

概述

DDD 方法需要不同类型的类元素，例如实体或值对象，并且几乎所有这些类元素都可以看作是常规的 Java 类。它们的总体结构是

Name: 类的唯一名称

Properties：属性

Methods: 控制变量的变化和添加行为

一般来说，DDD的实体、值对象和聚合根包含

把数据库表转换为Java类。包括类的名称和属性，还包括每个属性的类型，并符合DDD的模型数据库表和列的名称通常用带下划线分隔符的大写字母书写

类

用户需求决定一个类应该是实体、值对象、聚合根还是服务，它为给定的元素提供了或多或少的功能。实体和聚合根需要一个唯一的属性，该属性也是表中的主键列。稍后也可以更改此类型

然而，重新变回值对象或服务会消除唯一的标识。除此之外，聚合根与 Entity 非常相似。它可以被视为数据库中多对多关系的关联表。这里的情况也是为了使关系更容易。聚合根的另一部分是为服务提供方法。服务只包含没有任何属性的方法。服务和聚合根应该提供有界上下文中几乎所有的公共方法和不断变化的对象

添加新类: 如果决定从头创建一个新模型，也可能是这种情况。可以创建三种类型的新元素实体、值对象、聚合根或服务

属性

所有的属性都必须检查。数据库模型中的类型可能与用户期望的不同。NUMBER 就是这种类型的一个例子，因为它既可以是浮点数，也可以是整数。除了类型，名称也可以改变。此外，还可以添加其他属性或删除其中的一些属性

方法

为类声明简单的CRUD（创建、读取、更新、删除）方法，确保封装和对属性的访问

多数方法都应该在包中或受保护的可见性中，因为聚合根和服务应该向外部提供功能

从数据库中，只加载属性、属性与其他类之间的关系。这就是为什么用户可以声明元素的新方法，包括参数。

限界上下文

有元素都必须在至少一个有界的上下文中组织。这意味着通过避免对其他有界上下文元素的过多依赖来封装类元素。对于DDD，它有助于避免任何修改后不必要的副作用。首先，所有元素都可以放在相同的有限上下文中，但是用户应该考虑这种分离。可能是特定元素自有方法必须在多个有界上下文中使用，应通过在两个或多个有界上下文中复制同一元素来避免复制。因此，它们应该被放入一个共享的内核中

还应该可以将一个元素移动到另一个有界上下文，甚至可以复制该元素以在不同版本中使用。比如用户类。在“预约”有界上下文中，只需知道名称和电子邮件地址。但是，对于支付上下文中需要诸如信用卡号码之类的数据。如果在几乎所有有界上下文中都需要某些数据，那么这个类可能应该移动到共享内核。共享内核存储不同有界上下文的多个元素使用的所有类。它可以被看作是模型的核心部分。另一方面，核心类对更改的灵活性较差，因为它们可能在软件的其他几个地方使用。