Question

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

例如，如果用户查询通知，则应用程序应告知用户是否阅读了每个帖子。通常在这种情况下，我将使用如下数据进行响应：

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

假设有一个Notice实体和Read实体保存了一个User读过的实体。还要假设有太多的用户在阅读该通知，即为is_read检索所有用户并不是一种有效的方法。

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

Answer 1

我现在真的无法想到其他选择

我看到了两个可能使您绊倒的问题。

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

因此，将产生的视图看起来像与Bob的确认一起加入的活动通知列表。

让您烦恼的另一件事是，尝试使用存储库来获取数据的“手工”连接确实是一个障碍。此外，自从编写蓝皮书以来，人们已经意识到了什么，这可能不是必需的。由于查询是safe，因此它们不会更改基础数据-并且如果基础数据不会更改，我们真的不需要域模型来保护业务不变量。

Answer 2

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

埃里克·埃文斯（Eric Evans）的书是一个很好的基础，并且现在已经演变为更现代的模式，例如沃恩·弗农（Vaughn Vernon）的《实现域驱动设计（IDDD）》中的CQRS。

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

您可以在此处查看一些查询服务示例（用Java编写）：

Answer 3

我没有Read实体。只是通知和用户。在“用户”中，您将具有该用户已阅读的通知ID的列表（反之亦然，在“通知”中，您将具有已阅读该通知的用户ID的列表）。

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