我不太确定如何使用参与者来访问数据库。在Akka的文档和书籍中，似乎省略了该主题。
一种解决方案是将DAO封装在无状态参与者中。例如，对于数据库中的每个表(或域对象类型或聚合类型)，可以创建一个负责所有CRUD操作的参与者。这种变化可以是命令和查询的分离。例如，对于每种数据类型，1个命令参与者(用于并发)和10个查询参与者(用于并行性)。
另一种方法可能是创建有状态的actor，以准确地表示数据库中的一行(或域对象实例或聚合实例)。当然，在这种情况下，数据库也可以是事件存储(例如akka持久性模块)，并最终一致地投影到数据库，文档存储或缓存。这与这里无关。这种方法实际上是具有所有优点和问题的内存缓存的实现。必须有一种消灭 Actor 的策略，使其在一段时间后不会耗尽内存。
我将对DDD扩展我的问题:
假设我想与Akka Actor 一起开发DDD应用程序。让我们集中在命令部分。我认为这应该以这种方式实现:对于每个有界上下文，都会有一个端口参与者，例如Spray REST API，它将消息路由到适当的域服务参与者。该服务参与者将业务任务协调到一个或多个域模型聚合。每个单个聚合都是有状态的参与者，服务参与者从数据库中恢复(或在新数据上创建)。服务参与者将消息发送/路由到所有涉及的聚合参与者。接收域模型参与者将对其状态+消息执行业务验证，然后将其更改写入数据库，例如精巧的DAO。将done发送回服务参与者后，他们将停止。当所有聚合参与者完成后，done消息将被发送回消息的发送者。一种变化可能是不立即停止有状态域模型参与者，而是在一定时间间隔(例如3分钟)之后停止。
这是Akka DDD的有效使用模式吗？
最佳答案
通常，DB读取操作(cRud)可以由任何参与者直接执行。在大多数情况下，无需进行任何特殊处理。只是一个简单的循环来平衡负载。
至于更新操作(CrUD)，可以将它们划分为不相交的域/碎片。例如，具有单个帐户的所有操作最好应由单个参与者处理。例如，一个人可能具有N个几乎独立的处理角色，以及一个根据account.hashCode％N将命令路由到其中一个的路由器。因此，操作将或多或少地在参与者之间平均分配，并且每个帐户将被顺序处理。
附言Slick似乎是Akka应用程序的下降数据库库。
关于database - 如何使用参与者进行数据库访问和DDD？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25975995/