众说纷纭：
如果您正在寻找更好的方法，并且已经找到了CQRS/ES，那么它们是多余的。
如果actor用作聚合或事件投射，可以很好地与CQRS/ES一起工作，我过去曾在奥尔良做过。
因为这与人们被教导为Web应用程序的好东西（无状态计算）的模型相反？如果一个人的背景全是关于将状态问题推送到数据库的，那么可能很难理解Actor为什么有用。
抽象得过于复杂。构建一次性或一次性应用程序并不容易。这需要大量的学习投入。
我正在使用Actor系统。血腥的很难调试。为什么状态更改发生或没有发生。为什么一条消息从未得到答复。DI不能很好地工作。特别是对于MS DI或EF。由于没有作用域（我们将作用域定义为消息），因此必须为EF进行复杂的操作。
大多数应用都是CRUD。人们编写应用程序将数据扔到数据库中，并让它照顾并发性（无论是天真还是乐观）
而且仍然大多数人会弄错它并导致数据不一致。我都代码逻辑推理没有问题，但还是不确定，不如将数据扔到数据库中并假定它将解决所有并发问题。
在我的经验（非常有限）中：它调试困难，可组合性有限
因为云原生工具赢了。云产品中存在创建群集，服务发现，pub sub，监视，PaaS托管等功能。Actor框架中存在零退出策略。
难以引导（前期设计成本高，而“我将开始在此Web应用程序中抛出端点”要简单得多）和调试困难是两个主要原因。
如果在水平扩展时创建状态服务，则会变得非常复杂。
在大约4年使用.NET（fw和Core）中的actor框架构建各种应用程序后，我的个人感觉是：由于缺少调用栈，并且仅通过调用固有的清晰接口/类型安全性，很难调试应用程序发送消息。
与传统应用程序（DDD，洋葱架构）相比，其优势尚不清楚。难以推断整个系统状态。强制执行特定的编程方式。模型并非每个人都喜欢或适合。想想如何将所有现有领域模型重构到一组Actors？
强烈推荐 http://nact.io
这是编程思考的范式转变。以我的经验，大多数人对OOP并不完全精通，因此范式转换会带来额外的提升。
定义一个类专门来传送数据，这有点设计过头，这是一种思考问题的方法，这是大多数人不习惯的另一种方式。但是，如果您的解决方案很复杂并且需要可伸缩性，那就太好了。
我们不需要Actor带来的额外框架复杂性。我认为，只有在复杂性和并发性达到一定程度时，它们才能带来收益，而收益要超过模型的成本。在90％的情况下，crud很好。
actor的组合不及函数。如果将事情解耦得太多，则可能会失去类型安全性的许多好处。