问题标签 [dddd]

我们如何使用 CQRS/DDD 建模经典的多对多关系？

我知道 DDD 和 CQRS 的实现和解决方案往往是特定于域的，因此可能很难对这个问题提出一般性的答案。

但是，假设我们在Book和Author之间有熟悉的关系。这是一个经典的多对多关系。

对我来说， Book和Author是两个不同的实体，每个实体都属于自己的Aggregate Root，这似乎是最自然的。因此，明确地建模它们之间的多对多关系并不是要走的路。

我们如何为 AddBookCommand 建模？我们希望能够将一本书添加到我们的图书馆，并以某种方式声明特定作者写了这本书。我们如何建模（并保持）这种关系？

Book和Author似乎都不是价值对象的好候选人......

我仍在努力解决与 CQRS 风格架构相关的基本（和已解决）问题：

我们如何实现依赖于一组聚合根的业务规则？

以预订应用程序为例。它可以让您预订音乐会的门票、电影的座位或餐厅的餐桌。在所有情况下，只有有限数量的“物品”可供出售。

让我们假设某个事件或地点非常受欢迎。当新活动或时间段的销售开始时，预订开始很快到达 - 可能每秒很多。

在查询方面，我们可以大规模扩展，并将预订放在队列中，由自治组件异步处理。起初，当我们从队列中拉出保留命令时，我们将接受它们，但在某个时间我们将不得不开始拒绝其余的命令。

我们如何知道何时达到极限？

对于每个预订命令，我们都必须查询某种存储来确定我们是否可以容纳该请求。这意味着我们需要知道当时我们已经收到了多少预订。

但是，如果域存储是非关系数据存储，例如 Windows Azure 表存储，我们就不能很好地做一个SELECT COUNT(*) FROM ...

一种选择是保留一个单独的聚合根，它只跟踪当前计数，如下所示：

• AR：预订（谁？多少？）
• AR：事件/时间段/日期（总计数）

第二个聚合根是第一个聚合根的非规范化聚合，但是当底层数据存储不支持事务时，这些很可能在大容量场景中不同步（这是我们正在尝试的首先是地址）。

一种可能的解决方案是将保留命令的处理序列化，以便一次只处理一个，但这违背了我们的可扩展性（和冗余）目标。

这样的场景让我想起了标准的“缺货”场景，但不同的是我们不能很好地将预订放在延期交货上。一旦一个活动售罄，它就已经售罄，所以我看不出有什么补偿措施。

我们如何处理这样的场景？

我有一个使用存储库与数据库对话的系统。当它是远程服务时，正确的定义是什么？或更好，

存储库用于数据库，因为 [...] 用于外部 Web 服务。

我在很多地方都找到了关于 ServiceAgents 的信息，但我不知道这是否是正确的定义。

使用 Microsoft 技术（我们可以完全控制所有组件）使用 DDD（o 更好的 DDDD，因为我们使用 WCF）开发 n 层应用程序，最好的选择似乎是 STE 与 POCO（这最后一个强制使用 DTO） . 这是正确的？在您看来，在我们需要的地方使用 STE 和 DTO 是否有意义？

谢谢。

我开始使用 CQRS，并认为在我的表单上使用 Command 对象作为模型是最有意义的。我可以利用 DataAnnotations 对命令的一些客户端验证，客户端验证，使其非常干净......

我的问题...这会引起任何问题吗？如果我的命令没有默认构造函数，这会使这个过程变得不可能吗？我是否需要创建自己的可以构造函数注入聚合 ID 的 CommandModelBinder？

你的想法，我在任何地方都找不到这种技术，我假设因为它不起作用。

我对开发 DDD 应用程序非常有信心，但是当两个应用程序相互集成时，一个继续给我带来问题的领域是。我正在努力寻找有关该主题的任何有用的书籍或资源。诸如 EAI 模式之类的书籍深入探讨了消息传递模式和消息构造，但并未真正解释如何构建利用这些模式的系统。

我搜索了高低，我很确定没有示例应用程序可以演示如何集成两个系统。我了解异步消息传递的概念，但又找不到如何应用它的好例子。

SOA 上的资源似乎一直在重复相同的概念，而没有演示如何实现它们，而且往往似乎更关心向我推销产品。

以下是我正在努力回答的问题：

1. 每个应用程序都应该拥有自己的数据副本吗？例如，组织内的每个应用程序是否都应该拥有自己的客户端列表，并在收到消息后更新？

2. 在 DDD 堆栈中的哪个点传递消息？它们是领域事件的结果吗？

3. 我可以将异步消息传递和 WCF 结合起来还是必须选择？我是否将 WCF 用于请求/响应和消息传递以进行发布/订阅？

4. 一个 DDD 应用程序如何使用另一个 DDD 应用程序的服务？一个 DDD 应用程序应该通过其应用程序服务查询另一个系统的数据，还是应该已经拥有自己的本地数据副本，如第 1 点所述？

5. 显然我不能跨两个系统进行交易。我该如何避免这种情况？

如果我听起来很困惑，那是因为我是。我不是在寻找上述问题的答案，只是指出可以回答这个问题和类似问题的资源方向。

不知道如何缩短该标题。

我基本上是在尝试围绕 CQRS (http://en.wikipedia.org/wiki/Command-query_separation) 和相关概念的概念。

尽管 CQRS 不一定包含消息传递和事件溯源，但它似乎是一个很好的组合（从结合这些概念的许多示例/博客文章中可以看出）

给定某事物状态更改的用例（比如更新关于 SO 的问题），您是否认为以下流程是正确的（如最佳实践）？

• 系统发出一个聚合 UpdateQuestionCommand，它可能被分成几个较小的命令：针对问题聚合根的 UpdateQuestion 和针对用户聚合根的 UpdateUserAction（用于计数点等）。这些是使用点对点消息异步发送的。

• 聚合根做他们的事情，如果一切顺利，分别触发事件 QuestionUpdated 和 UserActionUpdated，其中包含外包给事件存储的状态.. 要持久化 yadayada，只是为了完整，这里不是重点。

• 这些事件也被放在发布/订阅队列中进行广播。任何订阅者（其中可能是一个或多个创建读取视图的投影仪）都可以自由订阅这些事件。

一般问题：确实是最佳实践，命令是点对点的（即：接收者是已知的）而事件是广播的（即：接收者是未知的）？

假设上述情况，允许通过 pub/sub 而不是点对点广播命令的优点/缺点是什么？

例如：在使用 Saga (http://blog.jonathanoliver.com/2010/09/cqrs-sagas-with-event-sourcing-part-i-of-ii/) 时广播命令可能会出现问题，因为Saga 在其中一个聚合根失败的情况下需要发挥的中介作用受到阻碍，因为 saga 不知道从哪个聚合根开始参与。

另一方面，我看到了允许广播命令的优势（灵活性）。

非常感谢任何帮助我清理头脑的帮助。

我刚刚进入事件驱动架构，想知道命名命令和事件的约定是什么。我知道很多：命令应该采用 DoSomething 的形式，而事件应该采用SomethingHappened 的形式。我需要澄清的是，如果我需要将“命令”一词附加到我的命令中，并将“事件”附加到我的事件中，例如 DoSomethingCommand 而不是 DoSomething 和SomethingHappenedEvent 而不是只是SomethingHappened。我还想知道社区首选公约背后的基本原理是什么。谢谢！

我在 DDD 上阅读的所有内容都暗示聚合中的状态必须是高度一致的。

这意味着如果需要冗余，则只能使用强一致性复制（例如 2PC、3PC 或 Paxos）。

您是否允许使用最终一致的复制，例如多主或主从？如果您确实使用了它们，那么在 DDD 术语中您仍然拥有“聚合”吗？这是常见的事情吗？

我正试图以Greg Young 的风格了解DDDD。

有很多关于如何使用 CQRS+EventSourcing 实现 DDDD 的讨论，并且有一些示例实现......总之它可能会很混乱......

在 Gregs 视图中，聚合没有 getter 或 setter - 只是发出相应事件的状态更改方法。

基本上，一个事件描述了过去发生的状态转换。它的数据描述了发生了什么变化。

有人说，这些数据可以通过附加数据来“丰富” 。这些额外的数据
从哪里来？

即我有User和Usergroup-两个聚合根（可以独立存在，有身份）。User有一个方法叫做AddToUsergroup.

如果我想用用户组的名称“丰富”事件（出于调试原因或类似原因），我该怎么做？

• 吸气剂不存在
• 用户组的内部状态不可访问

不允许将诸如存储库之类User的东西注入（我在这里吗？！？），例如

• 读取端存储库
• 事件存储库

底线问题：

• 能是否应该注入诸如存储库之类的东西来聚合根？
• 事件是否应该只使用通过参数和聚合的内部状态可用的数据？
• 事件是否应该只包含描述状态变化的最少数据？

而且（有点离题，但样本在这里）

• 应该AddToUsergroup采用Guid 而不是完整的聚合根？

期待您的回答！

华拉巴