最近一直在思考一個問題：有沒有這樣一種可能，就是一個領(lǐng)域模型的狀態(tài)不依賴于外部，它只負(fù)責(zé)接收外部的事件，然后根據(jù)這些事件做出響應(yīng)；響應(yīng)分兩種：

1）根據(jù)模型當(dāng)前的內(nèi)存狀態(tài)進(jìn)行業(yè)務(wù)邏輯處理，然后產(chǎn)生事件，注意：這個過程不會改變模型當(dāng)前的內(nèi)存狀態(tài)；

2）根據(jù)事件改變自己的狀態(tài)；

另外，也是最重要的，領(lǐng)域模型不用關(guān)心自己所產(chǎn)生的事件到底怎么樣了，比如不關(guān)心有沒有持久化，不關(guān)心是否和別的事件有并發(fā)沖突。它只管根據(jù)自己當(dāng)前的內(nèi)存狀態(tài)做上面這兩點的響應(yīng)；

如果這樣的設(shè)想有可能，那領(lǐng)域模型就是真正的中央業(yè)務(wù)邏輯處理器了，和CPU很類似了。這樣它才能真正快起來。

簡單的說就是：事件->模型->事件

模型只管響應(yīng)事件，然后產(chǎn)生新的事件

領(lǐng)域模型就是一黑盒，它只能幫你處理業(yè)務(wù)邏輯，其他的什么處理結(jié)果它一概不關(guān)心；當(dāng)然，領(lǐng)域模型肯定有它自己的狀態(tài)，但這個狀態(tài)是駐留在內(nèi)存的，和領(lǐng)域模型是一體的。

我為什么會有這個想法是因為，我在想，為什么要讓領(lǐng)域模型的處理邏輯依賴于它的處理結(jié)果是否被正確順利持久化了？感覺這很荒唐。

既然領(lǐng)域模型有自己的內(nèi)存狀態(tài)空間，他的所有邏輯也應(yīng)該只依賴于這個狀態(tài)空間，不再依賴于其他任何外部的東西。

當(dāng)然，以前我們設(shè)計的IRepository，實際背后都是直接從數(shù)據(jù)庫取。這樣的話，領(lǐng)域模型的狀態(tài)空間就是數(shù)據(jù)庫了。但是這樣其實很不好，因為為什么不用內(nèi)存作為領(lǐng)域模型的狀態(tài)空間呢？

現(xiàn)在再想想LMAX就是我剛才的想法的一個實際例子。

事件->模型->事件，這樣的設(shè)計，理論上并不需要必須要求單線程來訪問模型，因為領(lǐng)域模型不依賴于任何外部的狀態(tài)，只依賴于自己所在存活內(nèi)存空間；單線程有一個很大的好處就是可以防止并發(fā)沖突的產(chǎn)生。我們其實完全支持多線程或集群的方式，只不過這樣會有可能訪問到的領(lǐng)域?qū)ο蟮臓顟B(tài)是了老的，因為不同的機(jī)器之間的領(lǐng)域模型內(nèi)存對象的狀態(tài)需要做一些同步，訪問到老數(shù)據(jù)的可能性的大小取決于并發(fā)的大小以及機(jī)器之間數(shù)據(jù)同步的快慢；

LMAX之所以用單線程，是考慮了，這單線程的領(lǐng)域模型和性能之間，性能已經(jīng)可以達(dá)到他們的要求了。

這樣的架構(gòu)，領(lǐng)域模型中的任何一個對象的一次狀態(tài)更新至少會響應(yīng)兩個事件，舉個例子：

1）先響應(yīng)ChangeNoteCommand（command也是一種事件，可以理解為NoteChangeRequested），然后Note模型產(chǎn)生一個NoteChanged事件；

2）然后該事件（NoteChanged）最終又被發(fā)送到領(lǐng)域模型讓其響應(yīng)，此時，領(lǐng)域模型才去更改自己的Note狀態(tài)；

經(jīng)過這兩個事件的響應(yīng)，才完成了Note的最終狀態(tài)的修改；而我們以前都是從數(shù)據(jù)庫取Note，然后更改，然后保存到數(shù)據(jù)庫。這樣不慢才怪！

通過上面的兩次事件響應(yīng)，可以換來領(lǐng)域模型***的吞吐量。剩下的我們只要考慮：消息的序列化和反序列化、消息傳遞的速度、事件持久化的速度、并發(fā)沖突后重試的設(shè)計，以及消息丟失，等問題。但這些都不是領(lǐng)域模型該考慮的問題。這些外圍的任何問題，都不要讓領(lǐng)域模型自己去考慮，我們應(yīng)該對出現(xiàn)的各種問題逐個尋求解決方案。

每個問題的解決方案我大概理了下我的對策：

1. 消息的序列化和反序列化：這個簡單，用BinaryFormatter，或更快的開源序列化組件，可以達(dá)到每秒10W次每秒；
2. 消息傳遞的速度：用MSMQ，如果嫌太慢，就用ZeroMq，可以達(dá)到30W消息每秒；
3. 事件持久化的速度：由于事件都是跟著單個聚合根，所以我們只要確保單個聚合根的事件不會沖突（即沒有相同的版本號的事件）；為了更快的持久化，我們可以對事件按照聚合根或者其他方式進(jìn)行分區(qū)存放，不同的服務(wù)器存放不同的聚合根；這樣通過集群持久化的方式可以實現(xiàn)多事件同時被持久化，從而提高整體的事件持久化吞吐量；如單個mongodb server每秒持久化5000個，那10個mongodb server能每秒持久化5W個；
4. 并發(fā)沖突后怎么辦：一般來說就是選擇重試，但為了確保不會出現(xiàn)不可控的局面（可能由于某種原因一直在重試），那需要設(shè)置一個***的重試次數(shù)；超過***重試次數(shù)后不再重試，然后記錄日志，以供以后查找問題；這里的重試的意思是：重新找到對應(yīng)該事件的command，然后再次發(fā)送該command給領(lǐng)域模型處理；
5. 消息丟失：丟失就丟失了唄，呵呵；要是你覺得消息決不能丟失，那就用可靠的帶持久化功能的消息傳輸隊列，如MSMQ；當(dāng)然，就算消息丟失了，我們很多時候都要想想有沒有影響的，一般來說，消息丟失，至少我們是知道程序有問題了的，因為模型的狀態(tài)此時一定是不對的。我們可以通過在消息發(fā)出時和接收時記錄日志，這樣方便以后查找消息是在哪個環(huán)節(jié)丟的；
6. 任何其他的異常出現(xiàn)，這個我覺得如果都是托管代碼，那可以在必要的地方加try catch，然后記錄日志。至于是否要重試，還要看情形；

另外，如果是多線程訪問模型，或集群訪問，那很多時候訪問到的內(nèi)存的領(lǐng)域?qū)ο蟮臓顟B(tài)都是老的，那怎么辦？其實這不是問題，因為事件持久化的時候會被檢測到這種并發(fā)重復(fù)，然后對應(yīng)的command會被重試。

另外，這種架構(gòu)，傳輸?shù)氖鞘录录际呛苄〉模圆挥脫?dān)心消息傳輸?shù)男阅堋?/p>

目前就想到這些。后續(xù)再完善思路，

***，我一直認(rèn)為：知識決定命運，學(xué)習(xí)積累知識，而正確的思維方式是一切高效學(xué)習(xí)的基礎(chǔ)。所以要學(xué)會如何清晰地思考！

所以，我們最重要的是要學(xué)會如何思考。

呵呵！

原文鏈接：http://www.cnblogs.com/netfocus/archive/2013/03/26/2982152.html