我在教授
軟體設(shè)計(jì)課程，尤其是以使用案例圖在說明架構(gòu)設(shè)計(jì)時(shí)，每一個(gè)用套件(Package)所界定範(fàn)圍的系統(tǒng)，係指軟體應(yīng)用系統(tǒng)，但卻幾乎不會(huì)談及到資料庫。因
為，軟體應(yīng)用系統(tǒng)與資料庫是兩個(gè)不同的層次，甚至，把資料庫視為是應(yīng)用系統(tǒng)的 "私有倉儲(chǔ)(private storage)"，會(huì)比較恰當(dāng)。
不過，這衍生出一個(gè)問題，學(xué)員不容易分清楚如何 "mapping" 抽象面的架構(gòu)設(shè)計(jì)至實(shí)體的 IT 系統(tǒng)，尤其是資料庫的問題。所以，我會(huì)先帶一個(gè)問題問學(xué)員：在設(shè)計(jì)層次的考量中，進(jìn)銷存系統(tǒng)有幾個(gè)資料庫？
這一個(gè)問題要能回答得出來，其假設(shè)前提的考量必須要瞭解，在整體的架構(gòu)設(shè)計(jì)中，設(shè)計(jì)團(tuán)隊(duì)到底將 "進(jìn)銷存" 視為是一個(gè)，還是三個(gè)，甚至多個(gè)的子系統(tǒng)？
參考下圖1，這是把 "進(jìn)銷存" 視為是單一的系統(tǒng)，所以，資料庫只有一個(gè)。
好處是什麼？ 就是簡(jiǎn)單，開發(fā)也容易。進(jìn)銷存相關(guān)的資訊處理，都是在同一個(gè)資料庫內(nèi)，並沒有分散的問題，所以當(dāng)處理銷貨需要查詢庫存資訊時(shí)，只要下 SQL 敘述直接連結(jié)庫存的 TABLE 即可。
圖1、將進(jìn)銷存視為一個(gè)整體系統(tǒng)
參考下圖2，架構(gòu)設(shè)計(jì)之初時(shí)，就已把 "進(jìn)銷存"
分為三個(gè)子系統(tǒng)(Sub-system)，或者也可以稱之為元件(Component)，以凸顯子系統(tǒng)之間的溝通，是透過介面(Interface)的呼
叫。其實(shí)，論子系統(tǒng)的範(fàn)圍與規(guī)模，稱為 "模組(Module)" 更為適合，不過，我個(gè)人並不喜歡以 "模組"
二字來稱之，因?yàn)椋@個(gè)術(shù)語被業(yè)界給濫用了，已淪落為在業(yè)務(wù)面的術(shù)語，卻並沒有在實(shí)體的系統(tǒng)間，嚴(yán)格遵循透過介面的呼叫。
所以圖2，有三個(gè)資料庫。
當(dāng)銷貨人員處理銷貨需要查詢庫存資訊時(shí)，需要透過庫存系統(tǒng)所提供的介面來呼叫，介面的實(shí)做可能是 "Web Service"、"Java
Bean"、"Session Bean"、"COM+" 等，但絕對(duì)不能直接下 SQL
來呼叫位於庫存系統(tǒng)內(nèi)的資料庫，否則，就違背了圖2的整體架構(gòu)設(shè)計(jì)。不遵循整體架構(gòu)設(shè)計(jì)的規(guī)範(fàn)，私自偷偷連接，稱之為 "跳線"。
圖2、將進(jìn)銷存分成三個(gè)獨(dú)立的子系統(tǒng)
上圖2的抽象設(shè)計(jì)與IT面的實(shí)做技術(shù)，比較困難，也需要花較多成本，以專案為主(Project-based)的開發(fā)，時(shí)程短、預(yù)算
低廉，不容易達(dá)成圖2的設(shè)計(jì)目標(biāo)。但若重覆性的專案，專注在進(jìn)銷存這個(gè)領(lǐng)域上，有豐富足夠的領(lǐng)域知識(shí)(Domain
Knowledge)，且打算產(chǎn)品化(Product)，那麼，圖2的系統(tǒng)架構(gòu)來得有彈性很多，"進(jìn)"、"銷"、"存"
三個(gè)子系統(tǒng)(元件)，均可以隨意抽換，各自更新或改版，而不會(huì)影響到另一個(gè)子系統(tǒng)，如同 PC 主機(jī)板內(nèi)的硬體元件，可以造成 "PnP(Plug
and Play)" 的效果。
請(qǐng)注意，上述問題的提問，會(huì)有幾個(gè)資料庫，是指抽象的邏輯設(shè)計(jì)層面，可千萬不要與實(shí)體的資料庫混為一
談。例如，圖2雖然需要三個(gè)資料庫，但若以 Oracle 資料庫系統(tǒng)，DBA 可以將邏輯層面的三個(gè)資料庫，切分為三個(gè) "TABLE
SPACE"，然後放在同一個(gè)實(shí)體的 Oracle 資料庫系統(tǒng)內(nèi)；而若是 MS SQL 或是 MySQL，則是切割為三個(gè)
"database"，放入同一個(gè)實(shí)體資料庫系統(tǒng)內(nèi)。
當(dāng)然，若有地理位置或資料庫系統(tǒng)負(fù)載的問題，要分散至多個(gè)實(shí)體的資料庫系統(tǒng)，那也沒問題。例如，進(jìn)銷存位於三個(gè)地點(diǎn)不同的廠，各自配置了三個(gè)實(shí)體資料庫，各自存放自己的資訊。這也是圖2架構(gòu)設(shè)計(jì)的優(yōu)點(diǎn)，一切分合自如！
e
化的系統(tǒng)設(shè)計(jì)，即使是 ERP
如此重視資料存取與處理的系統(tǒng)，應(yīng)該要能摒除傳統(tǒng)以資料庫為中心的設(shè)計(jì)觀點(diǎn)，因?yàn)椋到y(tǒng)整體的彈性度會(huì)不佳，很難應(yīng)變需求面的頻繁變更，或是 IT
實(shí)體平臺(tái)，包括資料庫系統(tǒng)的變更等。設(shè)計(jì)重心應(yīng)該要轉(zhuǎn)移至 "Middleware"，這個(gè)術(shù)語可能太貼近 IT
平臺(tái)面了，倒不如乾脆這麼說，設(shè)計(jì)的重心就是回歸至以 "應(yīng)用系統(tǒng)"
為主，是觀察應(yīng)用系統(tǒng)可以提供那些服務(wù)(services)或功能(functions)，這些服務(wù)與功能其實(shí)就是系統(tǒng)一個(gè)個(gè)可以量化的子目標(biāo)(Sub-
goal)，次一步驟才是考量如何取得要能達(dá)成這些子目標(biāo)的資訊(資料)，要取得資訊，就是到實(shí)體的倉儲(chǔ)，也就是私有的資料庫系統(tǒng)去找，或是，透過標(biāo)準(zhǔn)的
程序，也就是透過標(biāo)準(zhǔn)的介面，至外部系統(tǒng)取得相關(guān)的資訓(xùn)來處理。