领域驱动设计：定义领域模型的边界答案

【问题标题】：Domain Driven Design: Define boundaries from Domain Model领域驱动设计：定义领域模型的边界
【发布时间】：2021-11-25 17:24:36
【问题描述】：

我正在做一个项目，我正在尝试利用领域驱动设计的概念。

我有以下领域模型：（对这个问题进行了简化）

让我先解释一下系统。

该系统用于监控来自网关的数据。在这种情况下，有两个网关，但实际上可能有更多。每个网关都有自己的实现，因此也有自己的实体。

系统示例如下：

一家公司有一个监控船舶数据的项目。

所以他们有两个网关。一个带有type Field-Device-Gateway 的网关和一个带有type HTTP-Client-Gateway 的网关。

第一个网关（field-device-gateway）可以有多个现场设备。现场设备是船上的小型设备。该设备接收来自船上设备的所有数据。这是通过必须在系统中设置的来源（如地址）。

第二个网关（http-client-gateway）可以有多个 HTTP 客户端。每个客户端可能有多个路由。

所以，网关也有变量。变量是用于获取特定数据集的配置。因此，在现场设备网关上可能有一个变量，指定从特定的device、特定的field device source、特定的field device 获取整数数据。

系统将使用新变量向现场设备发出请求。然后现场设备知道要发送什么数据。它会被系统接收并存储在数据库中。

那么，我在问什么？

目前，一切都是耦合的。我需要定义边界然后聚合，但我不知道从哪里开始。

如果我不创建边界，这只会变成一个巨大的耦合混乱，并且很难进行聚合。

那么，界限是什么？那么聚合呢，甚至还有聚合吗？一切都是自己的集合体吗？

如果一切都是它自己的聚合，我该如何执行一些业务逻辑，例如：只有存在网关、项目和公司时，变量才能存在。

【问题讨论】：

【解决方案1】：

在考虑边界之前，您必须回到域和子域。

问题空间是您的域（和子域），您的解决方案空间是您的Bounded Contexts。

在项目中应用 DDD 的第一个重要问题是识别您的子域，特别是将它们分为以下 3 个“家族”：

这种切割是由这个子域家族和领域专家推动的。

Bounded Context 是语境为王的语言边界。我们只知道一个概念的含义，这要归功于它的背景（这也是一种文化背景）。

Bounded Contexts的划分如何避免出错？

如果您考虑到这一切，您可以轻松地将您的对象（您的语言）分成这些Bounded Contexts。

对于您Aggregate 的问题：

【讨论】：