相关疑难解决方法(0)

我正在努力寻找任何适当的链接来设计模式,最佳实践或良好的基本架构原则,这些原则应该用于构建基于Actor的应用程序.我知道的那几个是:

博客文章,文章,WIKI,指南

• OTP设计原则用户指南
• 企业集成的模式和最佳实践(通常,可以应用于任何消息驱动的体系结构)
• James Iry关于与演员一起处理设计状态的系列帖子
• 由Ittay Dror 设计的Scala演员系列帖子
• 维基百科上的并发模式文章
• 可扩展的系统设计模式(与演员没有直接关系,但非常有用)
• 理解actor并发,第1 节,第2页,作者:Alex Miller

文件

• 对 Joe Armstrong 制作可靠分布式系统的分析
• Philipp Haller和Martin Odersky的Scalabale Component Abstractions
• 基于事件的编程,没有由Martin Odersky和Matthias Zenger 控制的反转
• 具有多头消息接收模式的演员 Martin Sulzmann

图书

• 演员在Scala由Philipp Haller和Frank Sommers
• 由Joe Armstrong 编写Erlang编程
• Erlang和OTP在行动中由Martin Logan,Eric Merritt和Richard Carlsson执导

实现

• Akka框架(Scala中演员的替代实现,具有多个Erlang行为的端口以及许多其他演员的重新演绎模式)
• Scalaz Actors(演员的作曲,策略和承诺)

演讲

• 戴尔舒马赫的演员思考
• Ulf Wiger拥有1000年历史的设计模式
• Jamie Ridgway 的基于演员的编程
• ШколаАктерскогоМастерства …

我\xe2\x80\x99m 目前正在学习Actor 设计模式或模型，它看起来很有趣。然而，我\xe2\x80\x99m正在努力寻找任何像样的现实世界示例来说明如何或在何处应用此模型（除了带有余额的简单银行帐户或游戏的敌人坐标的基本示例之外） ， ETC）。

作为我研究的一部分，我遇到了一个示例电子商务微服务应用程序 (eShopOnDapr)，其中订单是一个 Actor。这是否是一个可以使用 Actor 模型的真实示例？

这种设计模式可以或者应该与微服务一起使用吗？使用上面的示例，订购服务仅处理订单，而不处理产品或客户等。对我来说，订单可能是参与者是有道理的，但最好使用其他技术构建服务，例如使用 CQRS，甚至只是基本状态管理（创建一个 Order 实例并在每次更新时记录它\xe2\x80\x99s 状态）

正如你所看到的，在设计模式的这个领域，我还有很多东西需要学习，但如果有人能给我指出一些好的 doco 或 YouTube 剪辑，用一些很好的现实世界例子来解释这些事情，那就太好了。