Akka Actors可以取代服务层吗？

Question

这更像是一个设计和最佳实践问题。我正在转换应用程序以使用Actors和Futures。目前这些是层（在Akka混合之前）。

Play Controller -> Service layer -> (Slick) DAOs

现在想要像

这样的东西

Play Controller -> Actors ->Services (Now they'll return Futures) ->DAO

在这样做时，我发现由于原始服务层具有所有具有所需业务逻辑的方法，因此Actors层看起来就像一个中介。想知道是否可以（从设计的角度来看）摆脱服务层现在一切都将通过Actors？

Play controller->Actors (with business methods) -> business methods calling into DAO (which Service methods were doing before)

或继续使用现有的服务层并仅使用Akka Actors中的那些方法？保持服务层原样的风险是，所有服务方法都将保持公开，并且可以从其他任何地方自由调用（如果有人直接在控制器中调用Service方法（通过传递Actors）或其他东西，则打破模式。）

Answer 1

基于行动者的系统设计有两种方法：

• Actors只是一个多线程抽象，例如TaskExecutorŠ
• 演员是商业建模的基础，例如在Pac-Man游戏中GhostActor。

您需要问自己，您希望在重构时遵循哪一个。 为什么。

您提到的第一个选项（Actors通过期货与服务商谈）是一个多线程抽象。当你遇到一个主要的性能瓶颈时，你想要做到这一点。可能演员可以提供帮助，但还有许多其他工具可以做到这一点。

您提到的第二个选项（Actors replace Services）使用actor进行业务领域建模。 它非常强大。你把你的逻辑放在演员中，演员由较小的演员组成，演员由较小的演员等组成。它们中的每一个都代表了您的业务领域的一小部分。演员越小越好。使用这种方法有很多好处：

• 每个参与者都可以在内部使用不同的策略来获取和存储信息。其中一些可能通过Futures使用HTTP服务，其中一些可能使用actor通信，其中一些可能是事件源。
• 您可以在整个系统中使用声明性和人性化的抽象：演员。你只需要把你的大脑从思考技术障碍转向考虑业务障碍。
• 当您遵循一些简单的技术规则时，您的系统内置了可扩展性，而不会过多地考虑它。经过一段时间后，这些规则成为第二种性质。

当然，还有一些缺点：

• 有些业务领域无法轻易与演员建模。
• 您正在使您的系统完全依赖于一个工具包。

我希望这能以某种方式帮助你。如果你想对某些事情采取后续行动，那就大声说出来吧。谢谢！