问题描述
如果您熟悉Trello，将整个Trello板存储为演员（具有akka持久性）会是一个好用例吗？
Trello板包含：
- 列表
- 列表中的任务
- 每个任务可以具有注释和其他属性
在确定akka持久性是否是给定问题集的好用例时，通常的最佳实践或注意事项是什么？
解决方法
在任何情况下，事件源都非常适合Akka Persistence。
反过来，事件源通常也适用（请注意，您正在使用的几乎所有数据库都是事件源（具有异常频繁的快照，事件日志截断和清除旧快照的功能）。
当您要明确建模域中实体随时间变化的方式时，事件源非常有效：您正在有效地定义变化的代数。这种变化模型越丰富（即距创建/更新越远），就越适合事件源。反过来，这种变化建模有助于使系统的其他组件仅在需要时更新其状态。
Akka Persistence，尤其是与集群分片一起使用时，使您可以处理命令/请求，而不必在每个命令/请求上都从数据库中读取（基本上，当您带回已经持久的actor时，您将从数据库中读取数据，但是随后的命令/请求（直到演员钝化或死亡之前）都不需要进行此类读取）。 Akka中父母和孩子演员的模型也趋向于自然地编码多对一关系。
在trello板的示例中，我可能会
- 每个委员会都是一个持久的参与者，是它的父母
- 列表，这些列表是持久的参与者，并且是每个列表的父母
- 列出项目，它们也是持久性参与者
根据列表项下的内容，他们可能反过来拥有持久的儿童角色（例如，发表评论等）。
可能值得阅读有关域驱动设计的信息。尽管DDD不需要参与者模型（反之亦然），并且它们都不要求事件源（反之亦然），但我和许多其他人发现它们相互补充。
,这主要取决于应用程序要执行多少写操作。
Akka持久性是一种在确保数据持久性的同时实现非常高的写吞吐量的方法，即，如果actor死了并且内存中的数据丢失了，那是很好的，因为写日志会持久存储在磁盘上。
如果数据的持久性是必需的，而又不需要很高的写入吞吐量（假设应用程序每秒更新Trello板1次），那么将数据简单地写入外部存储就可以了。
,将整个Trello板存储为演员（与akka一起使用） 持久性）成为一个好用例
我想说参与者的大小应该与聚合根的大小匹配。将整个电路板设为“聚合根”似乎是一个非常糟糕的选择。这意味着该板上的所有操作现在都已序列化，并且不能同时发生。为什么更改卡号1的描述会与将车号2移到其他类别时发生冲突？为什么创建新的董事会类别与将3号卡分配给某人有冲突？
我的意思是，您可以使整个系统成为单个角色，而您不必在乎竞争条件，但同时也会破坏可伸缩性...