2017-02-15 68 views
2

假设我已将Employee Employee实体表示为actor。我有2个服务也被模仿为演员。他们两个都通过发送消息来操纵收到的员工的状态。现在我们假设两个服务正在处理同一个actor。现在,它是完全可能的雇员演员按以下顺序接收来自两个服务的一个状态改变的消息和B如何在actor模型中实现MVCC

Employee <- |a1|a2|a3|b1|b2|b3|

这是好的。但有时它不是

Employee <- |a1|b1|a2|b2|a3|b3|

也许a2是依赖于a1状态发生了改变,但b1改变了它

类似于数据库中,我们有交易使我们可以与单个快照/版本工作在整个交易周期内的数据。

在命令模式中,我们将锁定整个员工对象并更新其状态,类似于数据库将如何执行它。

那么演员是否有可能收到散装消息,这些散装消息将作为一个原子序列消息进行处理?或者,我对数据本身的建模是否有缺陷?

回答

5

因为我不知道a1-a3和b1-b3究竟代表什么,所以我只能假设正确回答问题。对我来说,看起来你的信息太细腻了。例如,也许a1-a3试图在每条消息中设置一个数据属性。 b1-b3也是一样。

但是,您的消息应该关注的是在员工上导致行为,而不是在设置个人属性。因此,正如你自己所建议的那样,将你的信息设计为行为,其中a1-a3会折叠成一个操作请求。这通常被称为命令模式,在那里你命令/告诉对象/演员做某事。这样做会导致每个消息有正确的事务边界。

请注意,上面我说“对象/演员”。您可以/应该在对象设计中使用相同的方法,而不仅仅是演员。从意图揭示界面和告诉你的领域模型来看,你希望它为你做什么,而不是将域对象/演员视为愚蠢的数据持有者。

这是我对你的问题的看法。 HTH。

沃恩

+0

这就是我结束了。无论我在事务块中写入什么变化,我都会使用单个消息发出完全执行该事务的消息!谢谢! –

1

他们都通过发送邮件操纵它已收到 一个Employee演员的状态。

好吧。根据定义,演员不会与任何其他演员共享其状态或其操作。任何状态操作在的一个消息处理的边界内是事务性的。一个Actor在这个意义上代表一个聚合。消息通常是域名事件/命令,并且具有泛在语言的范围和部分。 DDD推理在思考演员时有很大帮助。

我的两分钱

谢尔盖 <> <

+0

“突变/交易行为必须限制在一条消息内”。很高兴这是我们实际需要在演员模型中应用的那种模式 –

+0

因此,我真的很喜欢DDD和ActorModel范例如何相互融合,使得EventSourcing和CQRS成为自然选择,为最终一致性提供了适当的位置。 –

+0

@SergiyChernets我记得你在Microsoft Channel9节目中的演讲 - 服务结构上的DDD和CQRS。关于理论部分和图表的讨论非常棒,但(演示)实现有点低于我的预期。太笨重和大量的支持代码,这会将注意力从实际领域分散开来。我认为,问题是C#语法本身。我用Erlang实现了类似的概念,而且非常优雅。你有没有尝试过F#呢? – ajukraine