工作流化模式
如何提高服務對不斷變化的業務流程的適應性？
最容易想到的方法是每次都等待變化的需求，然後根據需求變化開發**，更新服務。這裡有幾個問題。首先，為了變更需求，你需要乙個完整的開發周期。其次，**變更意味著系統的很大一部分需要重啟——想一想一些諸如此類的問題吧：「我們昨天的計畫會不會受到這次更新的影響？」；「會對上個週期我們新增的那個類似的東西產生什麼影響？」等等。可以說越多的開發和測試就等於越長的上市時間。在我們的專案中，這意味著實施新的計畫需要幾個星期的時間，這會讓管理部門很不高興。這也意味著你的工作評定又降了一級，甚至更多。我們當然不能這麼做。
乙個較好的辦法是將應用中比較穩定的部分從經常改變的部分中分離出來。比如在我們的方案中，像顧客姓名、位址等人口統計資料應該就是與銷售方案無關的穩定因素。雖然如此，編排穩定的邏輯仍然是一項繁瑣且容易出錯的任務。或許，我們可以想個更好的辦法……
解決方案：在服務中引入乙個工作流引擎來處理不穩定的和經常變化的過程、以及編排穩定邏輯（stable logic）。
加乙個工作流可以極大地提高業務響應能力並保持業務敏捷性。如果某個競爭對手啟動了乙個很受歡迎的新方案，那麼這家公司就可以在一天之內回應乙個有競爭力的方案。這是真正的有形商業資產。
工作流引擎的另乙個優勢是能夠處理持續的過程。它把涉及多資訊互動的全部過程直觀地表示出來，使我們更容易對藍圖和過程有乙個清楚的了解，因此可以從業務的角度來除錯過程。 當然，工作流化也可以與其它模式結合。比如，很容易通過作業排程（幾乎所有的工作流引擎都支援）實現主動式服務模式。
流程編排（orchestrated choreography）是一種與工作流化密切相關的模式；這兩種模式都使用相同的底層技術：使用工作流引擎。不過，雖然底層技術一樣，但是不同的架構考慮方式卻會導致選擇不一樣的模式。比如，兩者之間乙個很明顯的不同就是工作流化侷限於乙個單獨的服務中，而流程編排則需要在服務間新增調整性工作流。
閱讀筆記之 《SOA架構模式》二
主動式服務 乙個解決辦法是讓服務對先前的結果進行快取，但這只能解決部分問題，因為這樣做資料就無法得到及時更新，並且時而也會有快取失效的情況發生，這時仍然需要連線其它服務。這種方法還有另乙個問題，那就是如果傳入的請求過多，在處理乙個請求的時候，其它的請求就會處於 等待 的狀態，這樣又會產生資源問題，因...
《企業應用架構模式》 閱讀筆記2
這方面的理論知識可以參考eric evans的 領域驅動幹設計 軟體核心複雜性應對之道 實踐相關的內容可以參考vaughn vernon的 實現領域驅動設計 也可以參考我的系列部落格 ddd 使用領域驅動設計思想實現業務系統。初學者在實踐ddd的時候，首先需要改變思維方式，業務領域的分析和建模是關鍵...
《架構之美》閱讀筆記四
今天我閱讀了 架構之美 第五章面向資源的架構在web中，這一章講到現在我們過分強調了軟體和服務，而卻忽視了資料，現在大多數組織機構更容易在web上找到資訊，而不是在他們自己的系統中。web在很大程度上是因為它增大了資訊共享的可能性，同時也降低了門檻。面向資源的架構的標識是向命名的資源發起邏輯請求的過...