[webdriver]

不變性是統領業務分析和高性能架構重要法門，通過業務上不變性分析設計，可以實現代碼運行的並發高性能和高擴展性。

不可變性是一種抽象，它並不在自然界中存在，世界是可變的，持續不斷變化。所以數據結構是可變的，他們是描述真實世界某段時間內的狀態。而狀態經常會被修改，如下面情況：
1.狀態被並發線程同時修改
2.多個用戶對一個共享對象(狀態)進行沖突性修改。
3.用戶提供了無效數據，應該被回滾。
在自然可變的模型下，會在上面情況下發生不一致性或數據破碎crushing，顯然可變性很容易導致錯誤。我們需要的是一種新視野，新角度，一種事務transaction視野，當你從事務性程序中看世界時，一切都是不可變的。這和蒯因與引用透明 中功能重復執行不可變原理非常類似，體現邏輯的線性特征。

[webdriver]

不可變性說得這麼玄，是不是和平常編程沒有太大關系呢？

完全錯誤。舉個例子，當你要對一個變量進行修改時，這個變量處於一個對象A內，你是直接對這個對象(A類的實例)內這個變量進行修改？還是重新創建一個A類新的對象實例，新的變量在新的對象實例中，然後替換掉原來的對象呢？

很多程序員對這麼一個權衡問題沒有過多考慮，基本是隨意選擇其中方案，甚至根據工作量多少為抉擇，這些不經意行為都為整個系統的性能留下禍根。

這個問題其實涉及到了不可變性的問題，如果A類被設計為不可變了，那麼就要采取第二個的方案，創建後替換，這個答案帶來兩個問題：
1.程序員如何知道A類是一個不可變的類？
2.不可變類為什麼能夠獲得性能提高？

關鍵問題是第一個，我認為我們可以通過OOA/OOD等建模方式明確哪個類為不可變，很顯然DDD領域驅動設計方法中，有值對象為不可變的概念，如果領域專家指定來自需求中哪個類是值對象，那麼我們程序員就容易在編程實踐中采取構建替換的辦法，從而又能照顧到了計算機底層的性能。

[webdriver]

我2006年在jivejdon按照DDD設計開發時，探索性地提出狀態可以表達設計為值對象概念，見實戰DDD(Domain-Driven Design領域驅動設計:Evans DDD)，雖然此後一直有反復和懷疑，但是最近看了如何打敗CAP定理？一文以後，比較肯定了自己當初想法，心中一塊石頭落地，這是一種探索的樂趣。

下面談談我如何在JiveJdon 4.5版本中如何把值對象狀態不可變性貫徹落實完整的情況，在之前版本因為心中不確定，所以對狀態修改時，沒有遵循上面提到的第二步法則，而是直接對對象字段修改，就好象直接去修改數據表字段那樣魯莽。

這種破壞性修改的惡果也讓我吃盡苦頭，就是數據出現嚴重的不一致性，如帖子更新狀態，經常是增加新帖後，在論壇列表的“最近更新”欄目出現的不是最後增加的那個新帖，有時正確有時錯誤，頭疼不已，當時是非常懷念基於數據庫的編程模式，因為這個功能只要通過一條SQL查詢就能完成，輕松而簡單，而JiveJdon是基於內存中的對象，這個功能是對對象的狀態進行修改完成的，方式不同，思路就不一樣了，後來雖然費了九牛二虎之力勉強正確，但是不夠優雅和輕量，一直是自己不敢面對的痛。

[webdriver]

現在理順了值對象狀態不可變性這樣一個思路，我幾乎三下五除二把JiveJdon這個功能就重構了，而且一次性調試通過。下面談談這個重構過程。先展示一下JiveJdon的設計類圖：

[webdriver]

將ForumThreadState這個經常變換的狀態和實體聚合邊界內其他變化是不一致的，慘遭DDD一書中的訂單價格變化案例設計為單獨的ForumThreadState，下面問題是，ForumThreadState變化是直接修改其中字段，還是重新構建一個ForumThreadState替換原來的，不幸的是我和大多數一樣，起初沒有太多留意走的是前一種辦法，繞了不少彎路。


(The end)