論文摘要
? ? 2014年12月眼刃，本人所在的深圳市XX科技有限公司啟動了一個銷售過程管理系統(tǒng)的開發(fā)項目，本人作為IT部門程序組經(jīng)理，擔任了此項目的系統(tǒng)分析師角色。該系統(tǒng)主要用戶為銷售和售前技術人員最欠。為銷售人員提供項目機會的創(chuàng)建、項目機會跟進的功能惩猫。為售前技術人員提供項目機會協(xié)助支持功能芝硬。本文介紹了幾種主要架構風格及特點，如調(diào)用返回風格轧房、獨立構件風格以及倉庫類風格拌阴，論述了該項目在軟件架構選擇過程中，為何選擇了三種風格的組合奶镶。最后迟赃，文章總結了采用該組合風格后帶來的好處及缺點。
論文正文
背景介紹
? ? 本人所在的深圳市XX科技有限公司是一個本土的電子元器件分銷企業(yè)厂镇，主要業(yè)務為代理銷售來自歐美捺氢、日本等多個品牌的電子元器件，公司有10多個辦事處剪撬，200多業(yè)務員及60多個技術支持人員分布在全國各主要城市摄乒。 公司主要業(yè)務為將國外品牌的電子元器件通過項目協(xié)同設計的方式分銷給國內(nèi)的制造企業(yè)及設計公司。銷售過程管理是公司核心業(yè)務流程，高層對此非常重視馍佑。2014年12月斋否，公司啟動銷售過程管理系統(tǒng)（內(nèi)部名稱為COP系統(tǒng)）的開發(fā)項目。該系統(tǒng)定位于公司內(nèi)部客戶服務人員的協(xié)同作業(yè)平臺拭荤，主要用戶為銷售和售前技術人員茵臭。系統(tǒng)為銷售人員提供 項目機會的創(chuàng)建、項目機會跟進功能舅世。而對于技術人員旦委，提供項目機會協(xié)助支持功能。如何鼓勵大家更好地服務有價值項目雏亚，同時避免資源過度集中缨硝，以實現(xiàn)公司整體價值最大化正是本系統(tǒng)著重要解決的問題。本人有幸在該項目中擔任系統(tǒng)分析師角色罢低，全程參與了該系統(tǒng)的需求分析查辩、架構設計、系統(tǒng)開發(fā)及上線工作网持。
主要架構風格介紹
? ? 在基本需求確認后宜岛，我們開始了系統(tǒng)架構的選擇。我們首先考慮到的是調(diào)用返回風格功舀，在該類風格中萍倡，最典型的是主程序、子程序風格辟汰，該風格應用廣泛列敲、曾經(jīng)作為結構化開發(fā)方法的主要選擇，具有結構清晰莉擒，維護方便的特點酿炸，缺點是主子程序劃分缺乏標準瘫絮，較難實現(xiàn)不同設計人員間設計的子程序復用涨冀，該類風格中另外兩個面向?qū)ο蠹胺謱蛹軜嫞嫦驅(qū)ο笤陬惖膶哟螌崿F(xiàn)高度內(nèi)聚麦萤，整個系統(tǒng)通過不同類的組合調(diào)用實現(xiàn)不同功能鹿鳖，便于類的復用，只是面向?qū)ο笫且粋€通用風格壮莹，類的劃分不同設計人員設計結果有很大不同翅帜，對實際架構設計指導意義不大。分層結構將整個系統(tǒng)按照抽象層次不同分為多層命满，每個層次的程序只需要負責與相鄰的上下兩層打交道涝滴，簡化了系統(tǒng)中調(diào)用關系復雜度，隨著一些成熟框架如SSH的流行，分層架構也得到了廣泛的應用歼疮。
? ? 接著我們評估了獨立構件類風格杂抽，進程通訊架構風格和事件驅(qū)動架構風格。進程通訊架構將系統(tǒng)建設成一個個獨立構件韩脏，構件間采用命名的消息傳遞來實現(xiàn)溝通與協(xié)作缩麸，事件驅(qū)動架構風格與進程通訊風格類似，也是將系統(tǒng)分各個為獨立的構件赡矢，不同的是不同構件間通訊不采用命名的消息杭朱，而是采用隱性調(diào)用的方式，先將一個個構件的過程注冊到某個事件中吹散，當這個事件發(fā)生時弧械，所有注冊到該事件的過程自動被觸發(fā)執(zhí)行。這類風格的好處是獨立構件間耦合度進一步降低送浊，方便構件修改及替換梦谜，缺點是觸發(fā)事件放棄了對被觸發(fā)執(zhí)行程序組的控制。
? ? 我們還評估了倉庫類風格袭景，作為倉庫類風格中最主要的數(shù)據(jù)庫系統(tǒng)唁桩，有著非常廣泛的應用，透過一個共享的中央數(shù)據(jù)庫耸棒，保存當前系統(tǒng)的數(shù)據(jù)狀態(tài)荒澡，其他獨立的數(shù)據(jù)處理單元，分別對數(shù)據(jù)進行包括增刪改查的操作与殃，中央數(shù)據(jù)庫管理系統(tǒng)透過自身機制如數(shù)據(jù)排它鎖单山，共享鎖等，實現(xiàn)數(shù)據(jù)高速訪問幅疼，數(shù)據(jù)一致性米奸，數(shù)據(jù)完整性。同時各獨立數(shù)據(jù)處理單元之間互相不受約束爽篷。超文本系統(tǒng)和黑板系統(tǒng)作為倉庫類風格中另外兩種悴晰，相對來講應用已經(jīng)不是那么廣泛，超文本系統(tǒng)主要應用于靜態(tài)網(wǎng)頁逐工，黑板系統(tǒng)由一個作為全局共享數(shù)據(jù)的黑板铡溪，一個控制單元和多個知識源組成，主要應用與專家問題解決系統(tǒng)泪喊。
架構風格選擇
? ? 結合我們公司需求和系統(tǒng)環(huán)境的實際情況棕硫，最終我們選擇了分層架構，事件驅(qū)動袒啼，數(shù)據(jù)庫系統(tǒng)這三種風格的混合模式哈扮。
? ? 首先我們?yōu)榱税惭b方便纬纪，采用了B/S架構，整體上將系統(tǒng)分為頁面表現(xiàn)層滑肉，業(yè)務邏輯層及數(shù)據(jù)持久層這三層育八。表現(xiàn)層采用jsp文件實現(xiàn)，業(yè)務邏輯層為一組java service赦邻，數(shù)據(jù)持久層采用mybatis xml文件實現(xiàn)髓棋。
? ? 實際業(yè)務需求調(diào)研時我們了解到用戶在多個地方有審批需求，比如業(yè)務機會階段變更到2階段時惶洲，項目名稱修改時按声，及項目非正常關閉時，考慮到可能還會有其他地方需要審批恬吕，而審批是一個比較獨立的功能模塊签则，有自己的一系列行為，審批功能可能也會隨著外部比如OA系統(tǒng)升級而做修改或替換铐料。所以這里我們采用了事件驅(qū)動架構渐裂，將審批功能分裝成一個獨立構件，將啟動審批流程過程注冊到審批事件中钠惩，各個需要的功能界面只需觸發(fā)審批事件即可柒凉。
? ? 在數(shù)據(jù)持久層，由于我們公司ERP系統(tǒng)采用的是Oracle EBS, 所有數(shù)據(jù)保存在Oracle數(shù)據(jù)庫中篓跛，而銷售過程管理系統(tǒng)與ERP系統(tǒng)大量基礎數(shù)據(jù)如客戶膝捞，聯(lián)系人，產(chǎn)品等是共用的愧沟，而且銷售過程管理系統(tǒng)產(chǎn)生的項目蔬咬，機會，服務記錄等數(shù)據(jù)又需要回到ERP數(shù)據(jù)庫以供報表系統(tǒng)使用沐寺。所以我們采用了將銷售過程管理系統(tǒng)數(shù)據(jù)直接保存在ERP數(shù)據(jù)庫中的作法林艘，與ERP其他模組數(shù)據(jù)用不同的scheme分隔開，需要共享的數(shù)據(jù)用數(shù)據(jù)庫中的授權完成混坞。方便共享訪問同時又保證了數(shù)據(jù)安全性狐援。對于公共池，考慮到很多人需要在這里做交互拔第，領養(yǎng)咕村、棄領场钉、維護蚊俺、查看等很頻繁，所以我們將各類公共池在數(shù)據(jù)庫中建成獨立表逛万，方便快速數(shù)據(jù)交互泳猬。
總結
? ? 項目耗時4個月時間最終成功上線批钠，上線后得到使用單位用戶和領導的高度認可，至今使用已經(jīng)超過兩年得封，后期維護過程中埋心，用戶單位由于業(yè)務分工及組織架構調(diào)整，項目池要求由原先的按照行業(yè)來劃分修改為按照地區(qū)來劃分忙上，由于我們將項目池分類定義在數(shù)據(jù)庫系統(tǒng)中拷呆，所以我們很快地就滿足了用戶的修改需求。另外疫粥，我們發(fā)現(xiàn)到采用該混合架構也存在一些缺陷茬斧，比如B/S分層架構帶來的頁面查詢性能不佳，隨著數(shù)據(jù)量的增加梗逮，首頁刷新時間一度增加到8秒以上项秉，針對這個問題，我們后來將首頁分成幾個塊用多線程的方式分別獨立刷新慷彤，現(xiàn)在速度提高至3秒左右娄蔼。
? ? 通過這個項目，本人更進一步了解到系統(tǒng)架構設計的重要性底哗，也意識到各類架構風格只為滿足核心業(yè)務場景系統(tǒng)需求的本質(zhì)岁诉。
