我想这个问题可能与事件采购/ DDD / Lambda架构，ESB，演员等任何事件系统有关......我标记了这个问题，以便有这些系统经验的人可以回答。
我正在尝试使用我的初创公司an original way to build user interfaces，使用DDD / Event采购世界中经常使用的概念，但应用于javascript单页应用程序。我想要的是一个纯粹的功能UI，我可以在其中重放内存事件日志以恢复UI状态（事件日志不会在浏览器关闭时持久存在，只是为了让事情易于推理并可能启用很酷的功能像UI撤消/重做免费，时间旅行调试器，如ELM ...）
我有时想知道如何为事件选择正确的抽象级别，因为在我看来，可能存在对刚刚发生的事情的多种“解释”。
基本上，在JS SPA中，在用户点击按钮，链接或类似内容后触发了许多事件。所以我可以在我的事件日志中添加一个条目作为这个低级事件（在管理它之后可以序列化）。但是，这个事件也可以解释为用户在高级抽象中所做的事情。
举一个例子，假设我的UI上有一个弹出窗口，显示在某个时刻。
当用户点击弹出窗口之外的任何地方时，应该关闭它。
我们现在假设用户点击弹出窗口外的div来关闭它。我应该在事件日志中添加什么事件抽象级别？
div？这3个事件抽象似乎对我来说是正确的：它们在过去描述了发生的事情，但是在不同的抽象层次上。所以我问自己一些问题：
答案 0 :(得分：0)
在所描述的示例中，我建议不要生成任何事件，因为您没有执行任何命令（更改应用程序状态的操作）。您可能希望仅在实际存在保存它的实际价值的情况下才会发生此类事件，或者您可以认为它在不久的将来会变得有价值，因此您可以使用所有这些信息生成某种报告对您的业务有价值。
背后没有硬性规定，这只是常识问题。你想解决什么问题？如果它正在实现重做/撤消，事件源不是你应该寻找的第一件事，“命令”模式可能是更好的选择。只使用事件采购，您将无法“免费”撤消/重做。考虑将您的答案分成多个，并更具体地说明实际目标。
另外，我的建议是尽可能远离SAGA。在可能的情况下同步执行操作总是更好，否则您的代码将很快变得混乱（可读性较差，语义距离不断增加）。如果你必须让它异步，更好的选择是利用“延续传递风格”，“承诺”。当所有其他方法都无法工作时，Sagas应该被视为最后的手段......但是当你可爱的noSql不支持ACID事务时，这种情况更可能出现在服务器端，例如：p。
如果我错了，请纠正我，但看起来你只想玩一种“新时尚方法”，并且没有任何实际原因尝试它。这很好，只要你可以使你的应用程序比它应该更复杂。 （开发和支持更昂贵）