我在我的项目中应用域驱动设计，我遇到了这样一个场景：用户操作在我的一个有界上下文中转换为命令，从而产生一个事件。但是，我发现我的其他有界上下文都不会关心使用此事件。基本上这个命令所做的就是在我的有界上下文中保存/更新状态。
我的问题是：
命令是否必须产生事件？
如果是这样，没有人在听重要吗？
问问题
436 次
3 回答
2
命令是否必须产生事件？
绝对不。
如果您将event sourcing其用作持久性策略，那么您的所有状态更改都将是“事件”。但是没有特别的理由必须在其他地方公开该事件。
Hyrum 定律是您可能不想广播事件的原因之一
有了足够数量的 API 用户，您在合同中承诺的内容并不重要：您系统的所有可观察行为都将取决于某人。
在您手头有足够的数据可以做出正确的猜测之前，不要猜测事件中应该包含哪些信息。
没人在听有关系吗？
在一个理想的世界里，不是真的——在实践中，成本很可能会影响决策。
于 2019-06-10T15:37:03.410 回答
0
命令是否必须产生事件？
不，它不是必需的，命令可以只修改实体的状态而不调度事件。正如在其他回复中所说，如果您使用Event Sourcing，您应该要求每次状态更改都产生域事件。
如果是这样，没有人在听重要吗？
是和否。
- 是的，因为没有好的或坏的模型，只有有用的模型，如果没有人在听，那么你的模型对任何人都没有真正的用处。
- 不，因为领域事件被称为不变量，它们反映业务事件并且仅在业务需求发生变化时才发生变化，因此它们是您的 API 的一部分（请参阅已发布语言的概念）。
于 2019-06-14T06:16:52.337 回答
0
产生事件的命令不是必需的，尽管它是可取的。事件最显着的好处之一是能够从头开始生成特定日期/时间的系统状态。如果您要为系统中的所有更改虔诚地冒泡事件，您将能够按顺序应用事件并使系统达到您的要求状态。
恕我直言，在那个时间点没有人在听并不重要。我假设您将事件作为应用程序的一部分保存到事件接收器/日志中。这样做有两个好处：
一个。如果您要发现可以从事件日志中受益的未来需求，那么您已经领先了一步。
湾。即使没有人消费该事件，如第一个响应中所述，能够在特定日期/时间生成系统状态也是一项很酷的能力。
持久事件和派生系统状态的模式源于事件溯源。您可能想更深入地了解它以了解它的好处。
于 2019-06-10T10:45:00.190 回答