让我们说我已经将我的员工实体表示为演员。我有2个服务也建模为演员。它们都通过发送消息来操纵它收到的Employee actor的状态。现在让我们说两个服务都在处理同一个角色。现在，员工参与者完全有可能从以下两个服务A和B
接收状态更改消息 Employee <- |a1|a2|a3|b1|b2|b3|
这很好。但有时它不是
Employee <- |a1|b1|a2|b2|a3|b3|
可能a2依赖于a1更改的状态，但b1已更改
与数据库类似，我们有交易，因此我们可以在整个交易生命周期内使用单个快照/版本的数据。
在命令式模型中，我们将锁定整个员工对象并更新其状态，类似于数据库的操作方式。
参与者是否可以接收将作为一个原子系列消息处理的批量消息？或者我的数据模型本身是否存在缺陷？
答案 0 :(得分：5)
由于我不知道a1-a3和b1-b3究竟代表什么，我只能假设正确回答这个问题。对我来说，你的消息看起来太精细了。例如，也许a1-a3试图在每个消息中仅设置一个数据属性。 b1-b3可能也是如此。
但是，您的消息应该关注的是导致Employee上的行为，而不是设置单个属性。因此，正如您自己建议的那样，将消息设计为行为，其中a1-a3将折叠为单个操作请求。这通常称为命令模式，您可以命令/告诉对象/ actor执行某些操作。这样做会导致每条消息的事务边界正确。
注意上面我说＆＃34;对象/演员。＆＃34;您可以/应该在对象设计中使用相同的方法，而不仅仅是演员。考虑意图揭示界面并告诉您的域模型您希望它为您做什么，而不是将域对象/角色视为哑数据持有者。
这是我对你的问题的看法。 HTH。
斯沃恩
答案 1 :(得分：1)
他们都操纵了收到的员工演员的状态 通过发送消息。
好。根据定义，Actor不与任何其他Actor共享其状态或操作。任何状态操作都是在一个消息处理的边界内的事务处理。在这个意义上，Actor代表聚合。消息通常是域事件/命令，并且具有范围和普遍存在的语言的一部分。 在考虑演员时，DDD推理会有很大的帮助。
我的两分钱
谢尔盖 ＆LT;＆GT;＆LT;