.net 具有事件源的域模型

愚蠢的问题…但如果我使用事件源，为什么我需要一个域模型呢

我有（当然有活动巴士）和

• 具有业务操作的应用程序服务，每个业务操作在基本验证后发送一个命令
• 接收命令的命令处理程序执行其他命令验证和发布事件
• 事件处理程序，用于处理事件、更新读取模型并将事件存储在存储库（事件源）中
• 提供读取模型的读取模型服务
• 前端（UI或其他）使用来自读取模型服务的读取模型…并利用应用程序服务进行业务操作

---

为什么我需要聚合根和域实体？附加层的功能是什么？

听起来您可能在命令处理程序中做得太多了。需要明确的是，命令处理程序的作用是接收命令、加载适当的聚合并将命令发送到聚合中。最后，它捕获聚合可能已生成的任何事件，并将其持久化，最后将其发布。这是我博客上的图表

有关典型CQRS+ES应用程序的更全面的逐步概述，请参阅我的帖子：

我希望这能为你澄清一些事情。

---

另外，您可能希望了解如何为CQR和ES创建聚合根。您可以发现post

EventSourcing很简单，您可以选择如何存储应用程序的状态。如果您没有解决特定的问题，您可能不需要域的模型，只需要创建一个简单的应用程序。域模型是应用程序正在解决特定业务问题的域的简化抽象。领域模型是您和您的团队成员以及领域专家之间进行沟通的工具。我建议你读一本优秀的书，或者下载一些关于领域驱动设计的简短介绍。

你不会

领域驱动设计是关于使用领域专家普遍使用的语言对软件进行建模。该模型可以是“关系”模型，但也可以是命令和事件的模型

在中，Eric Evans解释说，他希望不再强调战术模式（聚合根、存储库、抽象工厂）等，而是强调建模方法，例如有界上下文

---

他还解释了CQRS+事件源如何将DDD置于一个全新的角度。在许多方面，战术模式都是过去的残余，在过去，一切都必须是面向对象的，并且必须有一个底层关系数据库才能得到重视。那是当时，但现在是。

我真的读过那本指南！很好，干得不错。我想我正在努力证明额外的层和样板代码的开销是合理的。。。AR的概念似乎有点混乱……为什么不有一个简单的IConsumer和IValidator概念，其中命令处理程序将命令传递给消费者，消费者调用验证器（可能引发异常），然后创建、保存和发布事件？这似乎更符合SR原则。这个问题引发了一些重大的意见。我喜欢认为我在这些事情上相当务实。杰夫，你似乎是一个经验丰富的开发人员。既然如此，也许你正在构建的系统并不需要它们。然而，考虑到聚合的用途，它是值得的。它对行为进行了封装和建模。它这样做（理想情况下）没有依赖性。这使得它成为在有限的上下文中建模行为的一种很好的“战术”模式。哦，还有一个好处，它们相对容易测试。在对复杂系统建模时，这些都很有用。我读了第一本书。这是一本好书，但并没有真正解决我的问题。CRUD应用程序和具有高度复杂的域操作的应用程序之间存在某种差异……DDD文本和作者通常会忽略这一点。事实上，大多数应用程序都结合了CRUD功能和复杂的域操作。如果域本身真的可以定义为可能的命令及其影响（事件），那么就具有状态的实际实体而言，对域模型的需求是什么。你能给我一个需要域实体类的具体例子吗？当你与一个以上的开发人员一起工作，并且你希望你的代码易于理解并反映你试图解决的业务问题时，这是必需的。你能给我一个为什么的例子吗？那么，如果我的应用程序的域可以定义为一组命令对于事件，没有真正的理由我不应该跳过聚合根和具有自己状态的域实体？（顺便说一句，我非常尊重您在这方面的意见…）ARs是关于事务边界的，无论解决方案如何，您都需要事务边界。您仍然需要对事件流进行版本控制，以在存在争用时保护不变量。不仅如此，强制执行依赖于实体当前状态的业务规则将非常困难，因为您必须挖掘事件以重建所需状态的一部分（您可以通过ARs获得）。读取模型总是被认为是过时的，所以这不是一个选项。