-- 摘要
2019年8月，我司承接了某市醫療集團，智慧葯房項目，該項目主要為集團下屬36家社區衛生服務中心提供葯品統一目錄管理、葯品集中采購、庫存管理、處方合理用葯審核、葯品配發、自動化發葯設備驅動提供軟件支撐。在該項目中我擔任了軟件架構設計師一職，主要負責該項目的軟件架構設計工作。本文以智慧葯房項目為例，主要論述了
架構風格在項目中的具體應用，
在處方審核模塊中，采用了基於規則的系統風格，將18萬種葯品合理用葯規則作為基礎規則庫供處方審核調用，在自動化發葯設備協同中，采用了隱式調用風格，將處方配發任務和設備驅動進行解耦，在葯品采購和配發模塊中，采用了B/S+C/S的混合架構風格，通過使用這些
架構風格，提高了軟件設計質量和開發效率，最終項目成功上線，並獲得了用戶一致好評。
-- 背景
根據深化醫葯衛生體制改革規范葯求，推進葯品集中采購，增加葯品的供應保障能力，嚴格監督管理，保障葯品的用葯安全，所有醫療機構開出的處方，必須通過處方審核后，方可進入划價計費環節，未經審核的處方，不得進行計費和配發。2019年8月，我司承接了某醫療集團智慧葯房項目，該項目為醫療集團下屬36家社區衛生服務中心提供軟件支持，主要分為葯品供應模塊、葯房管理模塊、處方用葯審核模塊、葯品配發模塊、設備協同模塊。葯品供應模塊負責葯品庫存預警，供社區衛生服務中心葯房對葯品進行集中采購，並將葯品發送到省采招平台；葯房管理模塊主要進行一些基礎信息的維護，及關注葯品的庫存管理，葯品批號跟蹤；處方用葯審核模塊，負責對醫生開出的葯品進行合理用葯審核，將不合理的處方審核結果返回給醫生，提醒醫生修改處方；葯口中配發模塊，負責將處方中的葯品進行調配，打印用法用量標簽，確認發葯后扣減相應的庫存；設備協同模塊主要是驅動葯房中的一些自動化發葯設備，將要葯品信息發給設備上位機，根據設備葯品的效期進行排序，通過上位機程序調用下位機，驅動設備出葯。在該項目中我擔任軟件架構設計師職務，主要負責軟件的架構設計及中間件等技術的選型工作。
--問題回答，根據提干來
軟件架構風格描述了某一特定領域中的系統組織方式和慣用模式，反映了領域中眾多系統所共有的結構和語義，並指導如何將各個構件有效地組織成一個完整的系統，提高了架構的復用性，架構風格定義了用於描述系統的述語表和一組指導構建系統的規則，一般分為數據流風格：批處理、管道-過濾器；調用/返回風格：主程序/子程序、面向對象、層次結構；獨立構件風格：進程通信、事件驅動（隱式調用）；虛擬機風格：解釋器、基於規則的系統；倉庫風格：數據庫系統、超文本系統、黑板系統。可以為從多項目提供通用的解決方案，能夠極大的提高軟件設計的重用方法和加快開發的進程。
--簡介
在智慧葯房項目中，我使用了虛擬機風格、獨立構件風格以及B/S+C/S混合架構模式；虛擬機風格中的規則系統，能夠在你預先定義好的規則下，執行符合規則的一些行為，獨立構件風格包括進程通信和隱式調用，減少系統的耦合度，提供了系統的可擴展性。B/S架構風格是基於瀏覽器和服務器的軟件架構，他主要通過HTTP協議進行通信和交互，降低了維護升級的成本，C/S架構風格使得客戶端程序能夠處理更多的業務邏輯，更容易驅動硬件設備。以下正文將重點描述架構風格的應用實施過程和效果。
--以三個維度闡述
處方模塊模塊中，采用了虛擬機風格中的基於規則的系統風格，目前現有葯品目錄有18萬種，一個患者在不同的時間或不同的科室就診，每次就診會開出相應的處方葯品，判斷這些葯品之間是否存在相互作用，給葯方式是否正確，是一項巨大的工程，所以在處方審核模塊中，我使用了虛擬機風格中的基本規則的風格，《中國葯典》、《臨床葯物治療合理用葯原則》、《配伍禁忌》中對現有18萬種葯品間的合理用葯有明確使用規則說明，將這些葯品的相互作用做為基礎規則庫，再加上葯品說明書中明確指出的用葯規則及葯師制定的一些自定義規則，規則數據量較大，因此我們選擇了適合處理大數據的非關系型數據庫MongoDB，在醫生開出處方后，將處方中的葯品本位碼和規則庫中的規則進行配對，如果發現有存在相互作用、用法用量有誤等不合理處方時，及時將審核結果，不合理用葯的原因，發送到醫生工作站，讓醫生修改處方，處方審核模擬中使用了基於規則的架構風格，大大提高了葯師人工審核的工作效率，保障了患者的用葯安全。
在發葯設備協同環節，我采用了隱式調用風格，來簡化構件間的交互，隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件，項目中有多種不同的發葯設備，如果在發葯管理中直接驅動設備出葯，增加了應用系統和設備之間的耦合度，降低了擴展性，新增一台發葯設備時，不能快速對其進行擴展兼容，因此，項目中采用了開源的MQ消息中間件做邊連接構件，這個是Apache 基金下的核心開源項目 Kafka，配發系統在處方葯品調配時，作為生產者，將處方中的葯品信息發送給 Kafka，發葯設備作為消息的消費者，從Kafka中獲取發葯數據。這種方式相對於同步調用的好處就是，消息發送者將消息發給Kafka后，就可以去處理其它任務了，無需等任務處理結果，發葯設備如果在維護情況下，重啟了設備，不會因為沒收到數據，造成出葯失敗，只需要在啟動后，重新到Kafka中再次消費數據即可，在上文中提到的，處方審核時，碰到不合理的處方通知醫生，也同樣采用了隱式調用風格。
在葯師配發葯和發葯設備出葯環境，我采用了B/S+C/S的混合架構風格，B/S的優點：維護方便，系統功能改造后，只需要服務器端程序更新，即可實現所有的用戶同步更新，簡化操作，客戶端只需要安裝瀏覽器，無需單獨安裝系統。輸入系統服務地址就可以打開系統進行操作。缺點：可操控性不強，客戶端不能處理太多的業務邏輯，大都邏輯是由服務端處理完成。所有用戶使用的是同一套WEB程序，很難實現個性化的需求定制。相比較而言C/S的個性化定制和操控性要優於B/S，因此，我們在設備上位機上，選擇了winform+應用服務器的C/S架構。不同的設備所具備的功能不同的，界面設置、功能也大不相同，C/S很好的滿足了個性化定制的需求，而且上位面程序在訂閱到Kafka消息時，會調用下位機PLC程序，驅動設備出葯，這是Web程序無法實現的。在葯房發葯窗口電腦上的配發系統，采用了B/S架構，院內業務需求經常發生變化，采用B/S架構能夠方便業務功能擴展和及時更新，降低了運維成本。
-- 結尾
項目從2019年8月啟動到2020年10月歷時14個月，圓滿完成，順利完成驗收，並取得了客戶的一致好評，該項目運行一年多，也出現過一些小的問題，
由於醫院使用的是集團內部局域網，與外網隔離，給排查問題及維護增加了困難，一次發葯設備上的上位機不心小被葯房老師刪除后，不會重新安裝操作，上報我司后，我們聯系醫院信息科老師，在信息科的老師協助下，對軟件重新進行了安裝，此次事件，導致了設備停止工作了幾個小時，影響了葯房發葯效率。后來我司安排了1名售后維護該項目，這一年內也新增了一些發葯設備，由於選用了合適的架構風格，使得設備的接入及服務的擴展變得非常容易，在售后同事的協助下，系統至今運行穩定。該項目的成功，讓我意識到了使用了
架構風格的作用和價值，堅定了我對
架構風格應用的信心，合理選擇合適的
架構風格，能夠大大的提高了軟件設計的復用方法，加快開發的進程，在項目中起到事半功倍的作用。經過這次項目，我也看到了自己身上的不足之處，在未來還會不斷地更新知識，完善本系統的設計，使系統能夠適應國家醫改的變化需要，這是作為軟件從業的我為之努力的動力和方向。