不過Q這衍生出一個問,學員不容易分清楚如何 "mapping" 抽象面的架構a計臛_體的 IT pȝ(dng)Q尤其是資料庫的問題。所以,我會先帶一個問問學員Q?strong>在設a層ơ的考量中,進銷存系i有qր資料nQ?/strong>
這一個問要能回{得ZQ其假設前提的考量必須要瞭解,在整體的架構a計中,a計團隊到底?"進銷? 視為是一個,還是三個,甚至多個的子系i?
參考下?Q這是?"進銷? 視為是單一的系i,所以,資料庫只有一個?/strong>
好處是什| 是單Q開gҎ(gu)。進銷存相關的資訊處理Q都是在同一個資料n內,並沒有分散的問題Q所以當處理銯需要查詢n存資a時Q只要下 SQL 敘述直接連結庫存?TABLE 卛_?/p>
?、將進銷存視Z個整體系i?/font>
參考下?Q架構設a之初時Q就已把 "進銷? 分為三個子pȝ(dng)(Sub-system)Q或者也可以E׃為元?Component)Q以凔R子系i׃間的溝通,是透過介面(Interface)的呼 叫。其實,論子pȝ(dng)的範圍與規模Q稱?"模組(Module)" 更為適合Q不過,我個h並不喜歡?"模組" 二字來稱之,因為Q這個術語被業界i濫用了Q已淪落為在業務面的術語Q卻並沒有在實體的系i間Q嚴格遵循透過介面的呼叫?/p>
所以圖2Q?strong>有三個資料n?/strong>
畉貨h員處理銷貨需要查詢n存資a時Q需要透過庫存pȝ(dng)所提供的介面來呼叫Q介面的實做可能?"Web Service"?Java
Bean"?Session Bean"?COM+" {,但絕不能直接下 SQL
來呼叫位於n存系i內的資料nQ否則,違背了?的整體架構設a。不遵@整體架構a計的規,U自偷偷連接Q稱之為 "跳線"?/p>
上圖2的抽象設a與IT面的實做技術,比較困難Q也需要花較多成本Q以案Z(Project-based)的開|時程短、預? 低廉Q不Ҏ(gu)達成?的設a目標。但若重覆性的案Q專注在進銷存這個領域上Q有豐富_的領域知?Domain Knowledge)Q且打算產品?Product)Q那|?的系i架構來得有彈性很多,"????? 三個子pȝ(dng)(元g)Q均可以隨意抽換Q各自更新或改版Q而不會媄(jing)響到另一個子pȝ(dng)Q如?PC L板內的硬體元Ӟ可以造成 "PnP(Plug and Play)" 的效果?/p>
請注意,上述問題的提問,會有qր資料nQ是指抽象的邏輯a計層面Q可千萬不要與實體的資料庫Z 談。例如,?雖然需要三個資料nQ但若以 Oracle 資料庫系i,DBA 可以邏輯層面的三個資料nQ切分為三?"TABLE SPACE"Q然後放在同一個實體的 Oracle 資料庫系i內Q而若?MS SQL 或是 MySQLQ則是切割為三? "database"Q放入同一個實體資料npȝ(dng)內?/p>
當然Q若有地理位|或資料庫系ip載的問題Q要分散臛_個實體的資料庫系i,那也沒問。例如,進銷存位g個地點不同的廠,各自配置了三個實體資料nQ各自存放自q資訊。這也是圖2架構a計的優點,一?strong>分合自如Q?/strong>
e 化的pȝ(dng)a計Q即使是 ERP 如此重視資料存取與處理的pȝ(dng)Q應該要能摒除傳i׃資料庫為中心的設a觀點,因為Q系i整體的彈性度會不佻I很難應變需求面的頻J變_(d)或是 IT 實體q_Q包括資料npȝ(dng)的變更等。設a重心應該要轉移?"Middleware"Q這個術語可能太D IT q_面了Q倒不如乾脆這麼說,a計的重心就是回歸至?"應用pȝ(dng)" ZQ是觀察應用系i可以提供那些服?services)或功?functions)Q這些服務與功能其實就是系i׃個個可以量化的子目?Sub- goal)Q次一步驟才是考量如何取得要能達成這些子目標的資訊(資料)Q要取得資訊Q就是到實體的倉儲Q也是U有的資料npȝ(dng)LQ或是,透過標準? E序Q也是透過標準的介面,臛_部系i取得相關的資訓來處理?