偶爾翻開《程式設計師》雜誌2023年6月刊，看到一些關於soa與業務敏捷的文章，提醒我，我們的軟體設計忽略了一些很重要的東西。
我們在anydata的設計過程中，實現了對資料表現方式的靈活應變，在某種程度上實現了流程上的應變，但是很多東西都是由專業的it人員對系統進行調整實現的，因此如果客戶的業務出現變化，則必須通知我們的技術工程師，然後由我們的工程師對系統進行調整，從而保證it的變化，以適應業務的變化。這個過程不是很好，因為這需要我們工程師的參與，也就是說，客戶業務的變化時，需要通知我們的工程師，工程師對it系統進行調整，以適應客戶業務的變化。
這個過程中出現了我們的工程師，而且出現的機率過於頻繁了，我們應該想辦法減少工程師的在客戶業務變化過程中出現的機率，或者盡量不出現，客戶自己就可以根據業務的變化調整it系統。或許我們需要對客戶自己的工程師進行培訓。
對於流程命令的新增比較複雜，因為這需要我們的開發工程師參與，在開發部編寫流程命令，然後對流程命令進行測試，測試通過之後交給我們的服務工程師，由服務工程師給客戶公升級。如果可以通過指令碼的方式新增新的流程命令，則服務工程師可以非常方便的客戶**新增乙個流程命令。
這實現起來完全沒有困難。流程命令是顯示在程式介面上，供使用者運算元據時用的，一般需要乙個對話方塊，提醒使用者要進行的操作，並且在操作之後給出乙個提示，是否成功等等。由於我們的anydata中支援自定義的對話方塊，這個對話方塊可以在流程命令中被引用。在對話方塊中新增按鈕的訊息響應函式完全可以通過指令碼實現。所有的指令碼和自定義對話方塊都儲存在伺服器上。
還有一種辦法完全也可以實現流程命令的現場編寫。那就是在客戶的環境中增加乙個業務管理工作站，可以通過c#express在建立新的流程命令。當然這需要工程師具備簡單的程式設計能力。通過這種方式編寫的程式**也應該儲存在伺服器上，具體的說應該是儲存在流程設計器中，流程命令的**都被儲存在流程命令表中。
流程命令保證了我們可以隨時給業務資料增加新的操作，但是如果需要增加新的事件處理規則怎麼辦？例如在列印結束之後，我們應該在通知his系統，某個資料列印完成。如果我們把列印操作也作為流程命令來處理，也沒有問題，因為我們可以現場調整流程命令。如果將已經將列印內建到應用程式當中了，則只能通過指令碼程式設計來處理列印完成事件。
上面的事件是系統內部的事件，如果有來自系統外部的事件怎麼辦？例如在his系統中剛剛建立乙個新的檢查申請，his系統發出乙個訊息，則需要在我們的系統中處理處理這個訊息，怎麼辦？
我們在程式中有系統事件介面，可以將外部的訊息轉換為內部的訊息。訊息的處理函式完全可以通過指令碼實現。
我們的anydata客戶端本身就是乙個宿主程式，可以允許.net指令碼在其中執行，也提供了編輯指令碼的功能。不過，目前這個功能沒有得到足夠的重視，而且使用起來比較的不方便。我們只是在程式中有乙個指令碼編輯器，可以編輯系統的所有可能的事件，但是這種指令碼編輯器給人的印象不是很深刻，或許我應該重新給它起個名字，例如叫「系統事件管理器」，通過anydata處理使用者的業務規則，有兩個非常重要的功能，乙個是流程命令，乙個是系統事件。
另外，流程和系統事件都應該可以在流程設計器中進行編輯。並且將使用者自定義對話方塊（只能在anydata宿主程式中被建立和編輯）可以作為流程命令被呼叫。
關於業務和流程
在軟體開發階段，我們常常說到乙個詞 業務流程 但是這個詞具體是什麼意思，好像沒有幾個人能夠說得清楚。近期，為了研究設計模式，朋友發來乙個他們公司開發的軟體產品供我學習參考。拿到這款產品後，我思考了如下的問題 1 怎樣才能快速熟悉這款軟體產品，並能夠向他人描述這款產品？2 怎樣評價這款產品的設計模式是...
關於業務主鍵和邏輯主鍵
關於這個問題網上已經有很多的討論，現在綜合這些討論在加上自己眾多建模及資料倉儲工作中的經驗給出以下分析及取捨建議，供各位同行參考 一 業務的東西，是每乙個做軟體的最薄弱的，並且是最有可能受到客戶影響的，也是最會引起問題的。比如身份證，如果有系統的錶用此做主鍵，其他眾多表以此為外來鍵，當身份證從15位...
IT閱讀 關於「業務」
本文 開發當中常常聽說 業務 這個詞，什麼 業務為王 之類的詞不絕於耳，那麼什麼是業務？那麼到底什麼是業務，怎樣才能搞清楚業務？乙個農民出錢請科學家幫一忙，農民的要求很簡單，請科學家讓自己家耕地的牛吃的是平時的十分之一，幹的活是平時的十倍。然後科學家開始想辦法，最終得到的結論是 要滿足農民朋友的需求...