领域驱动设计，如何处理用户特定数据？答案

【问题标题】：Domain Driven Design, How do I deal with user specific data?领域驱动设计，如何处理用户特定数据？
【发布时间】：2018-10-08 15:08:55
【问题描述】：

阅读 Eric Evans 的 DDD 后，我正在尝试将其应用到我正在管理的项目中。有一些用户特定的查询数据，我不确定如何以 DDD 方式实现它。

例如，如果用户查询通知，应用程序应告知用户是否已阅读每条帖子。通常在这种情况下，我会使用如下所示的数据进行响应：

{
    "notices": [
        {"content": "foo", "is_read": true}, 
        {"content": "bar", "is_read": false}
    ]
}

假设有Notice 实体和Read 实体保存User 是否已读取它。还假设有这么多用户阅读通知，检索所有用户为is_read 不是一种有效的方法。

第一个选项似乎是假设用户查询通知并使用应用程序逻辑破坏域层。另一方面，第二个选项让我觉得我正在以一种不必要的复杂方式实现一个简单的功能。而且我现在真的想不出其他选择。对于这种情况，最佳做法是什么？

【问题讨论】：

【解决方案1】：

我现在真的想不出其他选择

我可以看到两个可能会让您绊倒的问题。

首先，您的域模型可能缺少一个重要概念。我们如何知道 Bob 是否阅读了特定的通知？域中可能有某个实体，可能是 Acknowledgement，它捕获 Bob 和他阅读的文档，以及可能对该域感兴趣的其他信息（他阅读了哪个版本的文档？什么时候？什么渠道？什么时候? 等等）。

因此，将产生的视图看起来类似于与 Bob 的确认相连的活动通知列表。

另一件可能会让您感到困惑的是，尝试“手动”进行连接，使用存储库来获取数据，是一个真正的拖累。此外，自蓝皮书编写以来，人们已经意识到，这可能没有必要。因为查询是safe，它们不会更改底层数据——如果底层数据不会发生变化，我们真的不需要域模型来保护业务不变量.

【讨论】：

【解决方案2】：

这需要全部放在查询服务中，

Eric Evans 的书是很好的基础，现在它已经发展到更现代的模式，例如 Vaughn Vernon 的书中的 CQRS，实现领域驱动设计 (IDDD)。

您的查询服务将负责显示通知列表，在单独的表中更新该用户的读取列。

您可以在这里查看一些查询服务的示例（用 java 编写）：

【讨论】：

分离读写不会导致代码库被复制吗？而且几乎每个域存储库都实现了单项检索，让它显示给客户端不是很简单吗？
代码被复制在 DDD 中不是问题。实际上它是一个专业人士，考虑一下：您想更新您的读取模型而不是您的写入模型，代码已经分离，您不需要检查回归的潜在引入。这是一场胜利

【解决方案3】：

我不会有 Read 实体。只是通知和用户。在用户中，您将拥有用户已阅读的通知 ID 列表（反之亦然，在通知中，您将拥有已阅读通知的用户 ID 的列表）。

然后，要查询您需要在用户界面中显示的信息，您有多种选择，正如 Vaughn Vernon 在他的《实施 DDD》一书中所说（第 512 页）：

【讨论】：