2017-02-15 177 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