藥品管理系統(tǒng)架構(gòu)設(shè)計(jì)案例分析

06藥品管理系統(tǒng)架構(gòu)設(shè)計(jì)案例分析目前一頁\總數(shù)四十四頁\編于十九點(diǎn)2需求分析需求分析的主要任務(wù)就是創(chuàng)建代表“目前”業(yè)務(wù)情況的業(yè)務(wù)模型，并將此業(yè)務(wù)模型轉(zhuǎn)換成“將來”的系統(tǒng)模型，包括功能需求和非功能需求。非功能需求又包括質(zhì)量屬性和各種約定。

通過對(duì)客戶的當(dāng)前業(yè)務(wù)的分析，我們得到當(dāng)前業(yè)務(wù)的基本需求。目前二頁\總數(shù)四十四頁\編于十九點(diǎn)2需求分析功能需求功能說明用戶管理用戶的創(chuàng)建、登錄、刪除和維護(hù)藥品管理藥品種類的添加、刪除和維護(hù)發(fā)貨單位管理發(fā)貨單位的添加、刪除和維護(hù)授補(bǔ)單位管理授補(bǔ)單位的添加、刪除和維護(hù)入庫批次管理添加入庫藥品、打印入庫單、簽字、入庫等出庫批次管理添加出庫藥品、打印出庫單、簽字、出庫等統(tǒng)計(jì)和查詢對(duì)庫存、已入庫和已出庫藥品數(shù)量統(tǒng)計(jì)效期管理對(duì)庫存藥品使用年限進(jìn)行管理目前三頁\總數(shù)四十四頁\編于十九點(diǎn)需求分析非功能需求質(zhì)量屬性說明可用性將系統(tǒng)的錯(cuò)誤限制在可控制的范圍內(nèi)可修改性控制實(shí)現(xiàn)、測(cè)試和部署變更的時(shí)間和成本性能在一定的時(shí)間限制內(nèi)到達(dá)系統(tǒng)的事件生成一個(gè)響應(yīng)安全性抵抗一定的攻擊并從攻擊中恢復(fù)可測(cè)試性允許在完成軟件開發(fā)的一個(gè)增量后，較輕松地對(duì)軟件進(jìn)行測(cè)試目前四頁\總數(shù)四十四頁\編于十九點(diǎn)2需求分析2.1定義系統(tǒng)

(1)

捕捉系統(tǒng)通用術(shù)語通用術(shù)語：描述系統(tǒng)行為過程中經(jīng)常出現(xiàn)的名詞。通過捕捉系統(tǒng)通用術(shù)語可以避免在項(xiàng)目團(tuán)隊(duì)成員之間對(duì)它們的理解出現(xiàn)偏差造成誤解。

術(shù)語說明用戶信息即系統(tǒng)中的用戶信息，包括用戶名、密碼、聯(lián)系方式等入庫單表示采購(gòu)藥品的具體情況效期藥品的最遲有效時(shí)間............目前五頁\總數(shù)四十四頁\編于十九點(diǎn)角色說明庫存管理員指負(fù)責(zé)記錄系統(tǒng)中藥品種類、出入庫管理的用戶管理員指負(fù)責(zé)系統(tǒng)中用戶的創(chuàng)建、維護(hù)和權(quán)限分配的用戶處長(zhǎng)指對(duì)藥品出入庫單進(jìn)行確認(rèn)并簽字的人員外部系統(tǒng)指希望通過一定接口與本系統(tǒng)進(jìn)行交互的對(duì)象

(2)

捕捉系統(tǒng)中角色和用例通過捕捉系統(tǒng)中的角色和用例目的是定義系統(tǒng)的范圍，找出并描述系統(tǒng)內(nèi)、外部必須處理的內(nèi)容，以及那些與本系統(tǒng)需要進(jìn)行交互的人或外部系統(tǒng)。

系統(tǒng)角色如下：目前六頁\總數(shù)四十四頁\編于十九點(diǎn)用例說明管理用戶信息每個(gè)庫存管理員需要對(duì)藥品的出入庫進(jìn)行登記管理，必須由管理員創(chuàng)建該賬戶，并且對(duì)其進(jìn)行了一定的權(quán)限分配，并且管理員可以對(duì)該用戶信息進(jìn)行維護(hù)。同時(shí)，這些活動(dòng)必須包括登陸與推出功能。查詢和統(tǒng)計(jì)指向用戶提供按一定方式排列的藥品出入庫等相關(guān)信息。而且，還要提供方便的查詢，以便用戶可以迅速的查詢到制定的藥品。提交入庫單用戶根據(jù)具體情況需要從外面采購(gòu)所需的藥品，在按照一定的方式填寫完成相關(guān)的信息時(shí)（為維護(hù)系統(tǒng)中存儲(chǔ)信息的一致性，一些相關(guān)的信息需要從系統(tǒng)已存儲(chǔ)的信息中讀取），形成入庫單，提交給系統(tǒng)處理。根據(jù)已找出的系統(tǒng)角色，分析其對(duì)系統(tǒng)的具體要求，找出系統(tǒng)的各個(gè)用例。目前七頁\總數(shù)四十四頁\編于十九點(diǎn)用例說明入庫單打印指用戶根據(jù)一定的查詢條件，選擇待打印的入庫批次信息，提交給系統(tǒng)處理，按一定的格式，打印出所需的實(shí)體入庫單。審查訂單指處長(zhǎng)出、入庫單，核定相關(guān)信息，并簽字。藥品管理管理員根據(jù)所采購(gòu)的藥品種類，維護(hù)系統(tǒng)中記錄的與業(yè)務(wù)相關(guān)的藥品種類信息。授補(bǔ)單位管理管理員根據(jù)庫存藥品出庫對(duì)象的相關(guān)信息，維護(hù)系統(tǒng)中記錄的收補(bǔ)單位信息。發(fā)貨單位管理管理員根據(jù)采購(gòu)藥品的發(fā)貨單位相關(guān)信息，維護(hù)系統(tǒng)記錄的發(fā)貨單位信息。外部系統(tǒng)交互指系統(tǒng)根據(jù)以后的擴(kuò)展需要，為系統(tǒng)與外部系統(tǒng)交互預(yù)留一統(tǒng)一接口?！壳鞍隧揬總數(shù)四十四頁\編于十九點(diǎn)根據(jù)上述分析，可以得到下面業(yè)務(wù)用例模型：

目前九頁\總數(shù)四十四頁\編于十九點(diǎn)2需求分析2.2

細(xì)化定義

(1)

細(xì)化用例

細(xì)化業(yè)務(wù)用例模型，是為了更加詳細(xì)地分析和描述用例。同時(shí)，將業(yè)務(wù)用例模型轉(zhuǎn)換成系統(tǒng)的用例模型。下面，以“角色”庫存管理員交互的用例進(jìn)行細(xì)化為例。目前十頁\總數(shù)四十四頁\編于十九點(diǎn)目前十一頁\總數(shù)四十四頁\編于十九點(diǎn)要素說明用例名稱提交入庫記錄簡(jiǎn)要描述庫存管理員根據(jù)藥品采購(gòu)具體情況、記錄選購(gòu)藥品，形成入庫單，提交給系統(tǒng)處理。事件流基本事件流（1）庫存管理員在待入庫的藥品名稱欄中輸入待入庫的藥品名稱；（2）系統(tǒng)根據(jù)用戶輸入，以列表的形式羅列當(dāng)前系統(tǒng)中存儲(chǔ)的符合庫存管理員要求的藥品種類的詳細(xì)信息；細(xì)化用例后，還需對(duì)用例進(jìn)行詳細(xì)描述，直到所有涉眾都認(rèn)可描述的內(nèi)容已經(jīng)能夠正確表達(dá)出他們的需求為止。在RUP方法論中指明通過闡述一個(gè)用例的名稱、簡(jiǎn)要描述、事件流、特殊需求、前置條件和后置條件等六個(gè)方面可以對(duì)用例進(jìn)行描述。下面以用例“提交入庫記錄”為例細(xì)化描述。目前十二頁\總數(shù)四十四頁\編于十九點(diǎn)要素說明事件流（3）庫存管理員根據(jù)實(shí)際情況的需求，選擇待入庫的藥品種類，并在各個(gè)入庫單項(xiàng)記錄的輸入框中輸入此入庫單項(xiàng)的相關(guān)信息（生產(chǎn)日期、有效日期、單價(jià)、發(fā)貨單位、核準(zhǔn)數(shù)量和實(shí)際數(shù)量），庫存管理員確認(rèn)信息無誤后，點(diǎn)擊“添加入庫單項(xiàng)”按鈕；（4）庫存管理員重復(fù)上面的工作，直至此次入庫記錄添加完畢；（5）系統(tǒng)羅列出庫存管理員此次入庫的所有入庫單項(xiàng)的詳細(xì)信息，庫存管理員確認(rèn)無誤后，點(diǎn)擊“添加入庫記錄”，系統(tǒng)根據(jù)數(shù)據(jù)庫中現(xiàn)有的入庫批次號(hào)自動(dòng)生成新的入庫批次，并將它們關(guān)聯(lián)起來。（6）該“提交入庫記錄”用例結(jié)束?！疤峤蝗霂煊涗洝睘槔?xì)化描述（續(xù)）目前十三頁\總數(shù)四十四頁\編于十九點(diǎn)要素說明備選事件流庫存管理員在輸入待入庫的藥品種類名稱時(shí)，系統(tǒng)不能查詢到相關(guān)信息時(shí)，則按一下步驟進(jìn)行：（1）在系統(tǒng)未查詢到庫存管理員所需的相關(guān)藥品種類信息時(shí)，提示庫存管理員是否需要添加新的藥品種類信息；（2）其次，撤銷此次入庫記錄的提交。特殊需求系統(tǒng)要保證入庫信息的一致性和完整性，不允許偽造數(shù)據(jù)。界面操作要合理，要考慮到庫存管理員操作順序等問題?！疤峤蝗霂煊涗洝睘槔?xì)化描述（續(xù)）目前十四頁\總數(shù)四十四頁\編于十九點(diǎn)要素說明前置條件待入庫藥品種類信息必須存在，不存在的藥品種類不能入庫。后置條件當(dāng)入庫成功，相應(yīng)藥品的庫存信息要及時(shí)更新為最新狀態(tài)?！疤峤蝗霂煊涗洝睘槔?xì)化描述（續(xù)）目前十五頁\總數(shù)四十四頁\編于十九點(diǎn)上面對(duì)用例的描述僅限于文字描述，還不夠形象。再以活動(dòng)圖的形式進(jìn)行建模描述如下：目前十六頁\總數(shù)四十四頁\編于十九點(diǎn)(2)結(jié)構(gòu)化用例

結(jié)構(gòu)化用例的目的是通過觀察這些已經(jīng)細(xì)化的用例，看能不能抽取出共有的、可選的行為，把這些共同的內(nèi)容建立為新的用例。這樣的好處是，可以消除冗余的需要以及改善系統(tǒng)整體需求內(nèi)容的可維護(hù)性。像“提交入庫記錄”用例中，“添加新的藥品種類”應(yīng)作為一個(gè)新的用例提取出來，以提高上面所說的需求內(nèi)容的可維護(hù)性目前十七頁\總數(shù)四十四頁\編于十九點(diǎn)3系統(tǒng)架構(gòu)設(shè)計(jì)架構(gòu)設(shè)計(jì)是將需求內(nèi)容轉(zhuǎn)換成設(shè)計(jì)模型的雛形以及用戶體驗(yàn)?zāi)Ｐ?，其目的是建立整個(gè)系統(tǒng)初步的解決方案，為詳細(xì)設(shè)計(jì)活動(dòng)打下基礎(chǔ)，這一階段的具體活動(dòng)如下：目前十八頁\總數(shù)四十四頁\編于十九點(diǎn)3系統(tǒng)架構(gòu)設(shè)計(jì)3.1

體系結(jié)構(gòu)的選擇

決定采取分布式的還是集中式的體系結(jié)構(gòu)，將是一個(gè)影響系統(tǒng)性能、可縮放性、可靠性、易用性及此應(yīng)用所能支持的客戶端類型的重要決策問題。

根據(jù)前期的需求知道，系統(tǒng)是為某單位設(shè)計(jì)的，考慮到后期的系統(tǒng)推廣應(yīng)用的可能性，采取分布式的體系結(jié)構(gòu)將更適應(yīng)于今后的變化。目前十九頁\總數(shù)四十四頁\編于十九點(diǎn)根據(jù)前期對(duì)需求的分析，決定采取基于.NetFramework3.0框架來構(gòu)建此分布式的信息管理系統(tǒng)

。.NetFramework3.0框架如下：目前二十頁\總數(shù)四十四頁\編于十九點(diǎn)基于三層結(jié)構(gòu)的框架如圖所示：目前二十一頁\總數(shù)四十四頁\編于十九點(diǎn)框架講解：UI（界面層）：職責(zé)是數(shù)據(jù)的展現(xiàn)和采集，數(shù)據(jù)采集的結(jié)果通常以實(shí)體對(duì)象提交給業(yè)務(wù)邏輯層處理。BL（業(yè)務(wù)邏輯層）：職責(zé)是按預(yù)定的業(yè)務(wù)邏輯處理UI層提交的請(qǐng)求。

（1）

業(yè)務(wù)功能子層負(fù)責(zé)基本業(yè)務(wù)功能的實(shí)現(xiàn)。

（2）業(yè)務(wù)流子層負(fù)責(zé)將業(yè)務(wù)功能子層提供的多個(gè)基本業(yè)務(wù)功能組織成一個(gè)完整的業(yè)務(wù)流（事務(wù)只能在業(yè)務(wù)流子層開啟）。目前二十二頁\總數(shù)四十四頁\編于十九點(diǎn)RA（資源存取層）：職責(zé)是提供全面的資源訪問功能支持，并向上層屏蔽資源的來源。(1)BEM（業(yè)務(wù)實(shí)體管理子層）：采用數(shù)據(jù)存取子層和服務(wù)獲取子層來提供業(yè)務(wù)需要的基礎(chǔ)數(shù)據(jù)/資源訪問能力。(2)DA（數(shù)據(jù)存取子層）：負(fù)責(zé)從數(shù)據(jù)庫中存取資源，并向BEM子層屏蔽所有的SQL語句以及數(shù)據(jù)庫類型差異。

(3)SA（服務(wù)獲取子層）：用于以SOA的方式從外部系統(tǒng)獲取資源。(4)CA（配置文件存取子層）：用于從配置文件中獲取配置信息或?qū)⑴渲眯畔⒈４娴古渲梦募?。Entity（實(shí)體層）：跨越其他三層，在這些層之間傳遞數(shù)據(jù)。目前二十三頁\總數(shù)四十四頁\編于十九點(diǎn)規(guī)則（約束）：

（1）系統(tǒng)各層次及層內(nèi)部子層次之間都不得跨層調(diào)用。

（2）Entity對(duì)象在各個(gè)層之間傳遞數(shù)據(jù)。

（3）需要在UI層綁定到列表的數(shù)據(jù)采用基于關(guān)系的數(shù)據(jù)集傳遞，除此之外，應(yīng)該使用Entity對(duì)象傳遞數(shù)據(jù)。

（4）對(duì)于每一個(gè)數(shù)據(jù)庫表（Table）都有一個(gè)DB

Entity

class與之對(duì)應(yīng)，針對(duì)每一個(gè)Entity

class都會(huì)有一個(gè)BEM

Class與之對(duì)應(yīng)。（5）有些跨數(shù)據(jù)庫或跨表的操作（如復(fù)雜的聯(lián)合查詢）也需要由相應(yīng)的BEM

Class來提供支持。

（6）對(duì)于相對(duì)簡(jiǎn)單的系統(tǒng)，可以考慮將業(yè)務(wù)功能子層和業(yè)務(wù)流子層合并為一個(gè)。

（7）UI層和BL層禁止出現(xiàn)任何SQL語句。目前二十四頁\總數(shù)四十四頁\編于十九點(diǎn).NetRemoting框架圖：

目前二十五頁\總數(shù)四十四頁\編于十九點(diǎn).NetRemoting框架介紹：.NetRemoting提供了一種允許

對(duì)象通過應(yīng)用程序域與另一個(gè)對(duì)象進(jìn)行交互的框架。首先，客戶端通過Remoting，訪問通道以獲得服務(wù)端對(duì)象，再通過代理解析為客戶端對(duì)象。這就提供一種可能性，即以服務(wù)的方式來發(fā)布服務(wù)器對(duì)象。遠(yuǎn)程對(duì)象代碼可以運(yùn)行在服務(wù)器上（如服務(wù)器激活的對(duì)象和客戶端激活的對(duì)象），然后客戶端再通過Remoting連接服務(wù)器，獲得該服務(wù)對(duì)象并通過序列化在客戶端運(yùn)行。這種框架提供了許多種服務(wù)，包括激活和生存期支持，以及負(fù)責(zé)與遠(yuǎn)程應(yīng)用程序進(jìn)行信息交互的通訊通道。目前二十六頁\總數(shù)四十四頁\編于十九點(diǎn)框架選擇：

由于該系統(tǒng)僅在局域網(wǎng)內(nèi)使用，用戶數(shù)量有限，因此，決定采取局域網(wǎng)內(nèi)的分布式的桌面信息管理系統(tǒng)方式實(shí)現(xiàn)此系統(tǒng)。根據(jù)前面的分析，我們采用.NetFramework3.0框架實(shí)現(xiàn)該系統(tǒng)的，采用.NetRemoting實(shí)現(xiàn)客戶端與服務(wù)器端之間的通信。目前二十七頁\總數(shù)四十四頁\編于十九點(diǎn)3系統(tǒng)架構(gòu)設(shè)計(jì)3.2系統(tǒng)架構(gòu)的分析與設(shè)計(jì)

架構(gòu)的設(shè)計(jì)對(duì)系統(tǒng)質(zhì)量屬性的實(shí)現(xiàn)起著決定性的作用，而架構(gòu)的形成又是由這些質(zhì)量屬性驅(qū)動(dòng)的。由于系統(tǒng)為簡(jiǎn)單的MIS系統(tǒng)，因此，下面著重對(duì)數(shù)據(jù)存取層和業(yè)務(wù)邏輯層架構(gòu)的設(shè)計(jì)進(jìn)行比較詳細(xì)的介紹。目前二十八頁\總數(shù)四十四頁\編于十九點(diǎn)(1)

數(shù)據(jù)持久層的架構(gòu)分析與設(shè)計(jì)

可維護(hù)性場(chǎng)景：

目前二十九頁\總數(shù)四十四頁\編于十九點(diǎn)性能場(chǎng)景：

目前三十頁\總數(shù)四十四頁\編于十九點(diǎn)安全性場(chǎng)景：目前三十一頁\總數(shù)四十四頁\編于十九點(diǎn)可維護(hù)性：架構(gòu)的設(shè)計(jì)不僅僅是面向客戶的，同樣需要面向開發(fā)人員的。在數(shù)據(jù)存取層中添加數(shù)據(jù)源訪問組件，通過在數(shù)據(jù)訪問層中添加一個(gè)數(shù)據(jù)庫配置組件，可以使系統(tǒng)的數(shù)據(jù)源快速的從一種類型轉(zhuǎn)換到另一種類型。滿足實(shí)際業(yè)務(wù)擴(kuò)展需要。

性能：由于系統(tǒng)采用分布式的結(jié)構(gòu)，雖然用戶數(shù)量有限，但如果用戶頻繁的向服務(wù)器端發(fā)送請(qǐng)求，勢(shì)必導(dǎo)致系統(tǒng)性能下降。因此，在數(shù)據(jù)存取層中添加SQL訪問組件，實(shí)現(xiàn)對(duì)數(shù)據(jù)庫更新操作的批量處理，減少訪問數(shù)據(jù)庫的頻度，對(duì)系統(tǒng)性能的提升有一定得幫助。安全性：數(shù)據(jù)的并發(fā)訪問是分布式系統(tǒng)的中的潛在威脅。同一時(shí)間，不同客戶端對(duì)同一數(shù)據(jù)記錄進(jìn)行操作必然存在并發(fā)一致性問題，如：丟失修改、不可重復(fù)讀和讀臟數(shù)據(jù)等。本架構(gòu)通過數(shù)據(jù)庫事務(wù)處理組件對(duì)這一問題進(jìn)行控制。數(shù)據(jù)庫事務(wù)處理組件通過對(duì)事務(wù)進(jìn)行隔離級(jí)別劃分的機(jī)制，維持了數(shù)據(jù)庫的ACID（原子性、一致性、獨(dú)立性和持久性）要求，提高了系統(tǒng)的安全性。目前三十二頁\總數(shù)四十四頁\編于十九點(diǎn)滿足以上質(zhì)量場(chǎng)景的數(shù)據(jù)存取層架構(gòu)：

目前三十三頁\總數(shù)四十四頁\編于十九點(diǎn)數(shù)據(jù)存取架構(gòu)分析：

該架構(gòu)主要包括：數(shù)據(jù)源組件、SQL訪問組件、SQL參數(shù)和結(jié)果集處理組件四大模塊。其中，數(shù)據(jù)源組件主要負(fù)責(zé)數(shù)據(jù)庫連接的管理；SQL訪問組件負(fù)責(zé)數(shù)據(jù)庫服務(wù)器的交互；結(jié)果處理組件模塊負(fù)責(zé)處理從存儲(chǔ)過程或查詢操作類返回的結(jié)果數(shù)據(jù)；在整個(gè)架構(gòu)中，凡是涉及到SQL語句參數(shù)的處理都交給類“SQL參數(shù)”。基于這種架構(gòu)的數(shù)據(jù)存取過程，滿足上述的預(yù)期目標(biāo)。目前三十四頁\總數(shù)四十四頁\編于十九點(diǎn)

(2)業(yè)務(wù)邏輯層架構(gòu)設(shè)計(jì)：

業(yè)務(wù)邏輯層作為MIS系統(tǒng)的關(guān)鍵部分，對(duì)系統(tǒng)的靈活性實(shí)現(xiàn)起著決定性的作用。在本系統(tǒng)的業(yè)務(wù)邏輯層架構(gòu)層中，采取了Fa?ade模式，下面簡(jiǎn)單介紹一下Fa?ade模式的好處：(1)網(wǎng)絡(luò)開銷小，客戶只需要和一個(gè)“門面Fa?ade”交互，只要一個(gè)網(wǎng)絡(luò)調(diào)用就可以完成業(yè)務(wù)邏輯；(2)客戶端表示層和業(yè)務(wù)邏輯層得到解耦，完全分離；

(3)高效可靠的事務(wù)處理；(4)良好的可重用性和可維護(hù)性。目前三十五頁\總數(shù)四十四頁\編于十九點(diǎn)Facade模式：目前三十六頁\總數(shù)四十四頁\編于十九點(diǎn)業(yè)務(wù)邏輯層架構(gòu)設(shè)計(jì)：Fa?ade模式在本系統(tǒng)中應(yīng)用：

通過前期的需求分析，我們將業(yè)務(wù)用例模型中需要完成的業(yè)務(wù)流，分解成原子級(jí)的業(yè)務(wù)功能（圖中的小圓圈），通過業(yè)務(wù)流（門面Facade）的整合，以實(shí)現(xiàn)業(yè)務(wù)用例模型中的預(yù)期用例功能。在系統(tǒng)開發(fā)期間，可以將業(yè)務(wù)流和業(yè)務(wù)功能的具體實(shí)現(xiàn)很好的解耦合，每個(gè)“門面Fa?ade”可以認(rèn)為成對(duì)應(yīng)了一個(gè)系統(tǒng)功能子系統(tǒng)，為系統(tǒng)的并行開發(fā)提供了可能。通過Fa?ade模式，給系統(tǒng)的可維護(hù)性和性能等質(zhì)量屬性實(shí)現(xiàn)，奠定了很好的基礎(chǔ)。根據(jù)前面分析知，系統(tǒng)采用基于.NetFramework3.0平臺(tái)的Remoting技術(shù)實(shí)現(xiàn)分布式的。在Remoting技術(shù)中，客戶端通過遠(yuǎn)程調(diào)用服務(wù)器端注冊(cè)的業(yè)務(wù)功能組件的指針，完成自身的業(yè)務(wù)處理需要。這種遠(yuǎn)程調(diào)用的機(jī)制雖然占用一定的網(wǎng)絡(luò)流量，但它對(duì)于系統(tǒng)代碼的安全性起到一定的保護(hù)作用。同時(shí)，方便系統(tǒng)的升級(jí)。目前三十七頁\總數(shù)四十四頁\編于十九點(diǎn)

業(yè)務(wù)邏輯層的一種可用框架：

目前三十八頁\總數(shù)四十四頁\編于十九點(diǎn)業(yè)務(wù)邏輯層架構(gòu)分析：

該業(yè)務(wù)邏輯層的架構(gòu)是前面Fa?ade模式的一種變形，他繼承了Fa?ade模式的所有優(yōu)點(diǎn)，同時(shí)，具體到我們的架構(gòu)中，它又實(shí)現(xiàn)了客戶端不必與業(yè)務(wù)對(duì)象直接交互?？蛻舳酥恍枰斎霕I(yè)務(wù)參數(shù)（業(yè)務(wù)請(qǐng)求對(duì)象），然后調(diào)用業(yè)務(wù)對(duì)象執(zhí)行器，通過對(duì)象執(zhí)行器委派到具體的事務(wù)處理對(duì)象，就可以通過結(jié)果響應(yīng)對(duì)象獲取業(yè)務(wù)執(zhí)行結(jié)果。該業(yè)務(wù)邏輯層架構(gòu)具備良好的維護(hù)性、可靠性和可擴(kuò)展性。目前三十九頁\總數(shù)四十四頁\編于十九點(diǎn)3系統(tǒng)架構(gòu)設(shè)計(jì)3.3結(jié)構(gòu)化設(shè)計(jì)模型