领域驱动设计:从领域模型定义边界

Question

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

我有以下领域模型：(这个问题简化了)

​

​

让我先解释一下系统。

这个系统是用来监视来自网关的数据。在这种情况下，有两个网关，但在现实中可能会有更多。每个网关都有自己的实现，因此有自己的实体。

该系统的一个例子如下：

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

所以他们有两个入口。一个带有type字段设备网关的网关和一个带有type HTTP客户端网关的网关.

第一网关(现场设备-网关)可以有多个现场设备.野外装置是船上的一个小型装置。这个设备接收来自船上设备的所有数据。这是通过必须在系统中设置的源(如地址)进行的。

第二个网关( HTTP -client-网关)可以有多个HTTP客户端。每个客户端可能有多条路由。

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

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

那我要问什么呢？

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

如果我不创造边界，这只会变成一个巨大的耦合混乱，使它很难形成聚合。

那么，界限是什么呢？那么集合体呢，有没有集合体呢？每件事都是它自己的总和吗？

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

Answer 1

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

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

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

Domain

• Supporting Subdomain

• Generic核
• 子域

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

Bounded Context是一个语言边界，上下文是其中的王者。我们只知道一个概念的意义，因为它的背景(这也是一个文化背景)。

如何避免Bounded Contexts划分中的错误

当存在技术或体系结构considerations

• When时，尝试将任务拆分为释放developers

• If --您有两个不具有相同定义的对象，那么它们必须位于两个不同的Bounded Contexts

中

如果考虑到所有这些，您可以轻松地将对象(您的语言)分离到这些Bounded Contexts中。

关于你的Aggregate的问题：

Entities

• 试图为每个类决定它是Entity还是Value Object (或Domain Service，但尽量避免)。