domain-driven-design - CQRS 还是应用服务？

Question

所以我喜欢我们应用程序中 CQRS 的概念，主要是因为我们已经支持事件溯源(从概念上讲，不遵循您在那里看到的任何规定)。然而，CQRS 似乎真的是面向大数据、最终一致性之类的。我们将永远是一个关系数据库应用程序，所以我不确定它是否合适。

我也有顾虑，因为我觉得我需要在我的应用层做一些特别的事情。在进行读取时，我需要强制执行安全性和过滤数据，这些传统上是在应用程序层中实现的。

我的第一个问题是，我的应用程序是否适合(传统的 MVC/Relational DB 应用程序)？还是拥有一个传统的应用程序层并使用 DTO Mapper 更有意义？

我的第二个问题是，从传统应用程序层向域模型发出命令是否有意义？我喜欢命令/命令处理程序和事件的想法。

让我澄清一下我的问题。我担心与授权相关的数据过滤。当用户请求数据时，必须有一个过滤器通过将它们全部删除(因此它们不会返回给调用者)、隐藏值或对数据应用掩码来限制对某些数据元素的访问。在一个人为的示例中，对于社会安全号码，发出请求的用户可能只能看到最后 4 个号码，因此结果将显示为 ###-##-1234。

我的断言是这个责任在应用层。我认为这是一个方面，其中对查询或命令的所有响应都必须通过此过滤机制。这就是我的 CQRS 天真之处，也许是命令从不返回数据，只是指向通过读取模型查找的数据的指针？

谢谢!

Answer 1

首先是: CQRS 和 关系数据库 不要互相排斥。在高级场景中，将基于 SQL 的 DB 替换为其他存储方式可能是有意义的，但 CQRS 作为一个概念并不关心持久性机制。

在依赖于角色和/或用户的多个 View 的情况下，薄读取层 可能应该提供多个结果集:

一个包含有权访问该信息的用户的完整 SSN。

对于无权查看该信息的用户来说，另一种方式是

...

这些可以存储在单独的数据存储中，但如果您使用单个基于 SQL 的数据库，它们也可以通过 SQL View 提供。

在 CQRS 中 申请服务仍然以 的形式存在命令处理程序 .这些可以嵌套，即首先处理授权，然后将命令发布到包含的命令处理程序。

public class AuthorizationHandler {

    public CrmAuthorizationService(CrmCommandHandler handler) {
        _next = handler;
    }

    public void Handle(SomeCommand c) {
        if (authorized) _next.Handle(c);
    }
}

// Usage:
var handler = new CrmAuthorizationService(new CrmCommandHandler());
bus.Register<SomeCommand>(handler.Handle);

通过这种方式，您可以嵌套多个处理程序，例如作为 REST 信封，用于日志记录、事务等。

回答您的问题:

第一: CQRS 是否适合您的应用程序？如果不真正深入研究具体要求，就无法判断。就 CQRS 的优缺点而言，仅仅因为您使用 MVC 和关系数据库并不意味着什么。

第二 : 是的，在某些情况下，让您的应用程序层以经典方式与客户端交互并处理身份验证、授权等事情，然后在内部发出命令是有意义的。当将基于 MVC 的 UI 或 REST API 放在您的应用程序之上时，这会很有用。

回复评论更新:

在理想的、纯粹的 CQRS 场景中，Sally 将为每个 View 拥有她自己的非规范化数据，例如NoSQL DB 中的几个文档，称为 CustomerListForSally、CustomerDetailsForSally 等。这些文档填充了她允许查看的内容。

一旦她得到提升——这将是一个重要的领域事件——她所有的非规范化数据将自动被覆盖，并扩展到包含她现在允许看到的内容。

当然，我们必须保持理性和务实，但这种理想应该是我们前进的总方向。

实际上，您可能拥有某种基于用户/角色或用户/组的系统。为了能够查看敏感信息，您必须是特定角色或组的成员。这些中的每一个都可以有其定义的 View 和命令集。这不需要去噪化数据它可以像 SQL-Views 一样简单:

CustomerDetailsForSupportStaff

CustomerDetailsForSupportExecutive 与未屏蔽的 SSN

CustomerListForSupportStaff

CustomerListForSupportExecutive 与客户收入总额

等