手把手邁向HIS微服務之路 (下)

口述／孫培然‧彙整／CIO編輯室

上期我們談到在我們要開發一個系統時，會先跟使用者訪談需求後，再由敏捷軟體開發小組撰寫一份系統設計書，系統設計書裡面的大綱有七大重點如下：

UI & Event Binding
ViewModel
View Service
WebAPI Controller
Mode Service
Stored Procedure
Interactive

首先要畫出 UI（User Interface），每個 UI 都要有 Event Binding，也就是某個按鈕按下去要做什麼動作。所以每一個按鈕都要定義一個事件名稱<圖1>，事件名稱前面一定要加一個 on，如 onAddClick 就是定義一個新增按鈕的選點事件。

我們跟使用者討論完把 UI 畫出來以後，就要開始寫每一個事件裡面所要產生的東西。產生出來的畫面可能會呈現很多內容，所以接下來就要把相關的 ViewModel 設計出來，如<圖2>所示，這就是一個前、後端共享的 ViewModel 類別。

第三個就是當 Property/Event 對應的按鈕按下去以後，會呼叫前端的哪一個 View Service，Input 及 Output 是什麼，都要列很清楚如<圖3>。

然後這些功能會相對到後端的 WebAPI Controller，如<圖4>，也就是要呼叫哪一個 API。如 API 的 Method 是要 GET 還是 POST，是 PUT 還是 DELETE？ URL 裡面是要呼叫的 API ，如「getAppStoreInfo」，以及 Input 及 Output 的內容。

WebAPI Controller 的下一個階段，則是要呼叫哪一個 View Model，也就是要呼叫Model Service，如<圖5>。要特別注意的是，從 View Service、WebAPI 到 Model，甚至到 Stored Procedure，如<圖6>，相關名稱除非有特殊性或差異性，不然功能名稱都要力求統一。

串聯整個系統的資料溝通機制，是透過底層共用的 ViewModel 來溝通，如<圖7>，所以從前端到後端，再到資料庫的 Stored Procedure，中間資料的傳遞格式都是用 JSON 的方式來做傳遞，完整對應到前、後端的 MVC 架構。這是每一個系統設計師所必須要規劃出來的架構，有了這個架構以後，就已經把單體拆成微服務架構了，而且整個程式碼、API 也都已經分類分好了，它們之間透過 ViewModel 來互相溝通，這系統設計書的七項大綱，是根據近幾年來，在建立微服務架構所累積的實務經驗，而整理出來的方法論架構，期望，對於想導入微服務架構的醫院或企業有所助益。

打造微服務要避免迷失

但俗話說：「水能載舟，亦能覆舟」，如果微服務架構用的不好，坦白講可能也會出問題。想要用的好，打造微服務架構時就應該要注意一些細節。

其實我現在一直在推廣「導入微服務重構現代化 HIS 架構」，期望台灣醫療數位轉型順利成功，但現在擔心的一點就是，大家雖然已經知道微服務很好，卻還是用舊有的傳統思維架構去看微服務，只是想要用新瓶來裝舊酒，最後無法執行時，卻說是新瓶子沒有用，就會更慘，因為單體跟微服務架構的觀念是完全背道而馳，所以還需要更深入的去談如何避免微服務的迷思，否則到時候問題會更大。

(本文授權非營利轉載，請註明出處：CIO Taiwan)