领域驱动设计：从领域模型定义边界
Domain Driven Design: Define boundaries from Domain Model
我正在做一个项目，我正在尝试利用领域驱动设计的概念。
我有以下域模型：（针对此问题进行了简化）
先解释一下系统
本系统用于监控来自网关的数据。在这种情况下有两个网关，但实际上可能有更多。每个网关都有自己的实现，因此有自己的实体。
系统示例如下：
某公司有一个监控船舶数据的项目。
所以他们有两个网关。具有 type Field-Device-Gateway 的网关和具有 type HTTP-Client-Gateway 的网关。
第一个网关（field-device-gateway）可以有多个现场设备。现场设备是船上的小型设备。该设备接收来自船上设备的所有数据。这是通过必须在系统中设置的源（如地址）实现的。
第二个网关（http-client-gateway）可以有多个HTTP客户端。每个客户端可能有多个路由。
所以，网关也是有变数的。变量是用于获取一组特定数据的配置。因此，在现场设备网关上可能是一个变量，指定从特定 device、特定 field device source、特定 field device.
获取整数数据
系统将使用新变量向现场设备发出请求。然后现场设备知道要发送什么数据。它会被系统接收并存储在数据库中。
所以，我在问什么？
目前，一切都是耦合的。我需要定义边界然后聚合，但我只是不知道从哪里开始。
如果我不创建边界，这只会变成一个巨大的耦合混乱，并且很难进行聚合。
那么，边界是什么？那么蕴呢，甚至有蕴吗？一切都是自己的聚合？
如果一切都是自己的聚合，我该如何实施一些业务逻辑，例如：只有存在网关、项目和公司时，变量才能存在。
在考虑边界之前，您必须回到域和子域。
问题 space 是您的域（和子域），您的解决方案 space 是您的 Bounded Contexts.
在项目中应用 DDD 的第一个重要问题是确定您的子域，特别是将它们划分为以下 3 个“系列”：
- 核心领域
- 支持子域
- 通用子域
这个切割是由这个子域家族和域专家驱动的。
A Bounded Context 是上下文为王的语言边界。我们只能通过上下文（这也是一种文化上下文）来了解一个概念的含义。
如何避免Bounded Contexts的除法错误？
- 当有技术或架构方面的考虑时
- 当您尝试拆分
Bounded Context 以将任务分配给自由开发者时
- 如果您有两个不具有相同定义的对象，那么它们必须在两个不同的
Bounded Contexts
如果你考虑到所有这些，你可以很容易地将你的对象（你的语言）分成这些Bounded Contexts。
针对您Aggregate的问题：
- 尝试判断每个 class 是
Entity 还是 Value Object（或 Domain Service 但尽量避免）。
- 您的
Aggregates 是可以驱动其他 Entities 的“一些”主要实体
我正在做一个项目，我正在尝试利用领域驱动设计的概念。
我有以下域模型：（针对此问题进行了简化）
先解释一下系统
本系统用于监控来自网关的数据。在这种情况下有两个网关，但实际上可能有更多。每个网关都有自己的实现，因此有自己的实体。
系统示例如下：
某公司有一个监控船舶数据的项目。
所以他们有两个网关。具有 type Field-Device-Gateway 的网关和具有 type HTTP-Client-Gateway 的网关。
第一个网关（field-device-gateway）可以有多个现场设备。现场设备是船上的小型设备。该设备接收来自船上设备的所有数据。这是通过必须在系统中设置的源（如地址）实现的。
第二个网关（http-client-gateway）可以有多个HTTP客户端。每个客户端可能有多个路由。
所以，网关也是有变数的。变量是用于获取一组特定数据的配置。因此，在现场设备网关上可能是一个变量，指定从特定 device、特定 field device source、特定 field device.
系统将使用新变量向现场设备发出请求。然后现场设备知道要发送什么数据。它会被系统接收并存储在数据库中。
所以，我在问什么？
目前，一切都是耦合的。我需要定义边界然后聚合，但我只是不知道从哪里开始。
如果我不创建边界，这只会变成一个巨大的耦合混乱，并且很难进行聚合。
那么，边界是什么？那么蕴呢，甚至有蕴吗？一切都是自己的聚合？
如果一切都是自己的聚合，我该如何实施一些业务逻辑，例如：只有存在网关、项目和公司时，变量才能存在。
在考虑边界之前，您必须回到域和子域。
问题 space 是您的域（和子域），您的解决方案 space 是您的 Bounded Contexts.
在项目中应用 DDD 的第一个重要问题是确定您的子域，特别是将它们划分为以下 3 个“系列”：
- 核心领域
- 支持子域
- 通用子域
这个切割是由这个子域家族和域专家驱动的。
A Bounded Context 是上下文为王的语言边界。我们只能通过上下文（这也是一种文化上下文）来了解一个概念的含义。
如何避免Bounded Contexts的除法错误？
- 当有技术或架构方面的考虑时
- 当您尝试拆分
Bounded Context以将任务分配给自由开发者时 - 如果您有两个不具有相同定义的对象，那么它们必须在两个不同的
Bounded Contexts
如果你考虑到所有这些，你可以很容易地将你的对象（你的语言）分成这些Bounded Contexts。
针对您Aggregate的问题：
- 尝试判断每个 class 是
Entity还是Value Object（或Domain Service但尽量避免）。 - 您的
Aggregates是可以驱动其他Entities 的“一些”主要实体