并发性 同步状态访问 - 我们不能让多个并发作业随意读取和写入状态 非阻塞事件处理 - 接收事件必须尽可能快，但是，处理可能会慢得多（即需要缓慢的 IO 操作，如网络调用）并且不应阻塞新事件的处理 订购 先进先出 - 事件必须按照发送到达的顺序进行处理 一次处理一个动作 - 或者更准确地说，动作应该一次读取和修改一个状态 可测试性和可靠性 单元测试覆盖率 鼓励使用不可变状态 …使用纯函数 我们认为我们真正需要的是一个以序列化方式处理事件的简单状态机： 对于可以立即更新模型状态且无需访问任何外部状态（即无需执行任何长时间 IO 操作（如网络调用））的事件来说，这是理想的选择。
棘手的部分是处理需要大量处理的事件而不阻塞其他事件的处理。在的 巴拉圭手机号码列表 是将此类事件的处理分为两部分：一个事件将使用适当的信息（即“正在进行的操作”）立即更新状态，然后将处理委托给后台效果处理程序，该处理程序将在某个时刻，发出另一个事件 - 具有异步操作结果的事件。 最后，我们选择了一个状态机，它可以一一处理事件（输入），以同步方式更新我们的模型（状态），并处理后台线程上的任何副作用，如有必要，该状态机还将事件发送到状态机： 虽然这种架构并没有消除处理并发操作的复杂性（仍然需要正确跟踪和处理这些操作，即启动、停止、过时时忽略等），但它确实为我们提供了一个坚实的框架，对状态一致性和可用进行了强有力的断言。
状态转换。 在我们踏上从头开始实现一切的旅程之前，我们对可用的解决方案进行了一些研究，并发现了这个框架的小瑰宝，莫比乌斯。事实证明，Spotify 的开发人员也面临着同样的问题，并且已经为我们解决了！ Spotify 的莫比乌斯框架 该框架使用起来非常简单（我们强烈建议查看它的wiki），并且可以归结为定义一些内容： 状态类，即： data class Model val loaded Boolean 事件，即： sealed class Events data class OpenProjectval id String Events data class Resultval project Project? Events 效果，即（后台长时间运行的操作）： sealed class Effects data class LoadProjectval id String Effects 状态转换，即： fun update =
| 
發表於 2024-5-14 11:49:28