如何使用演员进行数据库访问和DDD?

我不太清楚如何使用actor来访问数据库.在Akka的文档和书籍中,这个主题似乎被省略.

一个解决方案可以是无状态演员中的包装DAO.例如,对于数据库中的每个表(或域对象类型或聚合类型),可以创建一个负责所有CRUD操作的actor.其变体可以是命令和查询的分离.例如对于每个数据类型1命令actor(用于并发)和10个查询actor(用于并行).

另一种方法可能是创建在数据库中正好代表一行(或域对象实例或聚合实例)的有状态角色.当然,在这种情况下,数据库也可以是事件存储(如akka持久性模块),最终与数据库,文档存储或缓存的投影一致.这在这里并不重要.这种方法实际上是内存缓存的一个实现,具有所有的好处和问题.必须有一个战略来摧毁演员,一段时间后才会失去记忆.

我会就DDD提出我的问题:

假设我想用Akka演员开发一个DDD应用程序.我们在这里集中精力指挥部分.在我看来,这样做应该是这样实现的:对于每个有界的上下文,都会有一个端口演员,例如喷洒REST API,将消息路由到相应的域服务actor.该服务演员将业务任务协调到一个或多个域模型聚合.每个单个聚合是由数据库中的服务执行者恢复(或由新数据创建)的有状态的actor.服务执行者向所有相关的聚合角色发送/路由消息.接收域模型actors将对其状态消息执行业务验证,然后将其更改写入数据库,例如.光滑的DAO.发送完成后,他们停止了服务演员.当所有聚合参与者完成完成消息时,发送回消息的发送方.一个变化可能不是立即停止有状态的域模型演员,而是在一段时间之后,比如3分钟.

这是否与Akka的DDD有效的使用模式?

解决方法

通常DB读取操作(cRud)可以由任何actor直接执行.在大多数情况下,无需特别处理.只是一个简单的循环来平衡负载.

对于更新操作(CrUD),它们可以分为非相交的域/分片.例如,具有单个帐户的所有操作应优选地由单个角色处理.例如,可能有几个独立的处理演员和一个基于account.hashCode%N将命令路由到其中一个的路由器.因此,操作将在或多或少地均匀地分布在演员之间,并且每个帐户将被顺序处理.

附: Slick似乎是Akka应用程序的下降db库.

相关文章

SELECT a.*,b.dp_name,c.pa_name,fm_name=(CASE WHEN a.fm_n...
if not exists(select name from syscolumns where name=&am...
select a.*,pano=a.pa_no,b.pa_name,f.dp_name,e.fw_state_n...
要在 SQL Server 2019 中设置定时自动重启,可以使用 Window...
您收到的错误消息表明数据库 'EastRiver' 的...
首先我需要查询出需要使用SQL Server Profiler跟踪的数据库标...