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