问领域驱动设计理念及其与CQRS的关系

EN

作为@expandable回答的补充：

CQRS、聚合、事件来源等只是工具。经验表明，它们在DDD项目中运作良好。使用这些工具并不意味着要执行DDD。

DDD是通过开发人员和领域专家之间的对话来提取一种无处不在的语言。在这些讨论中，你会注意到某些词根据上下文的不同而有不同的含义。

例如，您可以考虑在线零售店(如Amazon)产品的生命周期。经过与领域专家的讨论，您可能会发现，根据购买的生命周期，产品具有不同的含义。在零售环境中，产品是关于价格和描述的，而在运输环境中，重要的是目的地地址以及产品的大小和重量。

这是使用两种语言的线索，您可能必须为每种语言创建一个有限制的上下文(零售和送货)。有界上下文表示使用一种语言的域的一个区域。当语言的词义开始变化时，语境边界就会出现。

开发人员和领域专家讨论后确定的有界上下文需要与代码库对齐。在本例中，您可能会创建一个用于零售的包和另一个用于发货的包。有界上下文实现通常彼此之间是完全解耦的。例如，每个有界上下文都有自己的产品类，具有不同的属性。

每个边界都可以有自己的体系结构: CQRS、事件源、六边形等，这取决于需求。但是，您应该注意，您选择的体系结构与有界上下文的域是很好地一致的。例如，如果您的域不是基于事件本身的，您可能不会使用事件源。

我认为，将这些原则(DDD、CQRS、Event )结合在一起( DDD、CQRS、Event)，对DDD本身带来的危害大于利益。您的问题就是一个很好的例子，许多人认为DDD = CQRS + ES (有时是+ microservices )。

在其核心部分，DDD与CQRS和ES无关，因为它只是一个设计“框架”，而CQRS和ES是实现模式。换句话说，当您戴着DDD帽子时，您不应该考虑CQRS或ES，因为您正在设计软件，而不是实现它。

为什么CQRS是适合DDD设计的？答案是，答案不是:)。对于事件源系统来说，这是一种很好的实现模式，而且事实证明，当您按照DDD原则设计事件源系统时(主要是当您找到了良好的有界上下文和适当的聚合根时)，您可以很容易地创建一个好的事件源系统。

因此，连接点仅在CQRS和ES之间。Greg，CQRS术语的作者，创造了它作为事件源架构模式的介绍。没有某种CQRS，很难创建一个ES系统。但完全不需要DDD。当然，这三者都能很好地结合在一起。

对于您认为DDD是CQRS中的主要概念之一的想法，我认为您错了。

许多来源在线，解释CQRS作为一个类固醇的CQS，这是完全误导。CQRS的核心概念是将读取和 and 分离成两个完全分离的应用程序。写部件不应该知道read部件，而read知道read部件的每一个细节(包括任何私有/隐藏数据)。DDD与此无关。正如我前面所说，CQRS使ES能够从DDD中获益。

回答你关于一个标度的问题:这取决于。更大的系统更有可能从CQRS中受益，因为会有更多的特性、更多的视图、更多的用户希望以不同的方式查看系统。我认为这更多地取决于用户的数量和类型，而不是软件的规模。CQRS使您能够很容易地在相同的数据上创建不同的视图，这是大型软件将从中受益的主要因素。

关于DDD和项目规模。这里没有关联。当您的软件是CRUD类型时，根本不使用 DDD。域设计是仅针对复杂领域的软件的专用。

简短的回答是:是的，你可以。

CQRS作为一种建筑风格出现在DDD之后。它是基于命令-查询分离(CQS)的。

作为一种模式，CQRS可以用于优化应用程序。如果需要同时向多个集合的用户显示大量数据，则可能需要进行大量数据库查询才能获得这些数据。这可能会变得效率低下。以下是您可以选择的一些选项(当然不是完整的列表)：

• 选项1：折衷您的域模型以满足这一需求，并使其更适合阅读。
• 选项2:与CQRS完全分开。保持一个很好的、代表您的域的写模型，同时有一个读取模型，表示您希望如何将您的数据显示给用户。
• 选项3设计您的用户界面/前端不同时显示所有数据。例如，以用户界面在手机中的工作方式为例。因为它们有较小的屏幕，较慢的CPU和较少的RAM和最重要的事情:电池一直在断电，它们通常会显示一小部分数据，然后导航以查看更多的数据。提出一个又一个的请求，而不是有一个巨大的请求，并在一个屏幕上显示所有的东西。您可以将其与具有丰富菜单的桌面应用程序进行对比，打开它们时会向您展示大量内容。

这确实带来了您可能不想管理的额外复杂性，因此您可以根据您的组织选择选项1或3 (让用户以这种方式设计UI可能很棘手，因此您可能会选择选项1作为折衷方案)。

根据我的经验，除非您正在开发一个将处理来自许多用户的数据的应用程序(比如200,000，甚至可能会很好)，否则您可以跳过CQRS。如果您以后有这个问题，您可以随时重构到它。拥有一个很好的域模型使以后更容易引入CQRS。

如果你还没有读过DDD书，我强烈建议你读。

以下是CQRS的一篇伟大文章。讨论了大多数人如何认为必须使用单独的数据库，使从写到读端的传播是异步的。

为这两个模型拥有一个数据库并使传播同步是很好的。如果您使用事务性数据库来避免最终的一致性，甚至可以在同一事务中对读取模型进行更新。这将降低复杂性，但如果您的写端也有很重的负载，则可能会导致额外的延迟。如果是这种情况，您可以使用异步的、最终一致的解决方案，并处理由此带来的后果。

应用一些初步分析，看看CQRS是否会带来任何价值。如果它真的开始的话。如果没有，那就开始吧。如果您是DDD和CQRS的新手，最好不要在同一个应用程序中同时使用它们，因为您可能会引入意想不到的复杂性并陷入困境。从DDD开始，获得它的经验，然后您可以尝试CQRS。