一个解决方案可以是无状态演员中的包装DAO.例如,对于数据库中的每个表(或域对象类型或聚合类型),可以创建一个负责所有CRUD操作的actor.其变体可以是命令和查询的分离.例如对于每个数据类型1命令actor(用于并发)和10个查询actor(用于并行).
另一种方法可能是创建在数据库中正好代表一行(或域对象实例或聚合实例)的有状态角色.当然,在这种情况下,数据库也可以是事件存储(如akka持久性模块),最终与数据库,文档存储或缓存的投影一致.这在这里并不重要.这种方法实际上是内存缓存的一个实现,具有所有的好处和问题.必须有一个战略来摧毁演员,一段时间后才会失去记忆.
我会就DDD提出我的问题:
假设我想用Akka演员开发一个DDD应用程序.我们在这里集中精力指挥部分.在我看来,这样做应该是这样实现的:对于每个有界的上下文,都会有一个端口演员,例如喷洒REST API,将消息路由到相应的域服务actor.该服务演员将业务任务协调到一个或多个域模型聚合.每个单个聚合是由数据库中的服务执行者恢复(或由新数据创建)的有状态的actor.服务执行者向所有相关的聚合角色发送/路由消息.接收域模型actors将对其状态消息执行业务验证,然后将其更改写入数据库,例如.光滑的DAO.发送完成后,他们停止了服务演员.当所有聚合参与者完成完成消息时,发送回消息的发送方.一个变化可能不是立即停止有状态的域模型演员,而是在一段时间之后,比如3分钟.
这是否与Akka的DDD有效的使用模式?
解决方法
对于更新操作(CrUD),它们可以分为非相交的域/分片.例如,具有单个帐户的所有操作应优选地由单个角色处理.例如,可能有几个独立的处理演员和一个基于account.hashCode%N将命令路由到其中一个的路由器.因此,操作将在或多或少地均匀地分布在演员之间,并且每个帐户将被顺序处理.
附: Slick似乎是Akka应用程序的下降db库.