面向領域的業務平台設計(一)


畢業后,做了很多年的中間件,有工作流,有數據持久層框架,還有個類似tomcat的server等,一直在思考,一個最適合業務的平台應該是什么樣子的。因一直沒有業務經驗,因此,盡管有一些想法,但是也不知道這些想法靠不靠譜,最近一年參與了一個CRM項目的設計,積攢了一些業務經驗,心中的想法逐漸清晰了起來,也有了一些底氣,寫下來跟大家交流探討。

就如同變化多端的八卦卦象是由乾、兌、離等8個基本卦象組成,萬事萬物是由數種原子構成,形態各異的高樓大廈是由磚頭和砂漿砌成,應用也有構成其的“元”,即構件。

業務應用是分層的,典型的分層是展現層、流程層、服務層、數據持久層,每一層次的關注點都不同,構件也不相同,比如一個業務邏輯層的構件輸出的數據,會通過展現層的構件來展現在界面上。且各層之間的貫通黏合(如MVC中的Controller層就是黏合邏輯),通常要耗費比較多的開發精力,一個好的業務平台,除了在各層次分別提供可復用的構件,需要能夠減少各層黏合的工作量。

面向特定領域的業務平台的易用度與其適用面是魚和熊掌的關系,針對特定領域,要越易用,則平台能力就要越面向特定領域,則越不通用,導致適用面越窄。因此,一個好的平台,要注意分層,比如分成通用的構件和領域化的構件。業務用戶可按需使用。同時,還需要在各層次開放定制能力,供業務用戶在各層提供領域構件。

現在的產品交付都是解決方案級的交付,解決方案由多個系統或子系統構成,一個部門,一個項目組通常只是提供解決方案中的一個部件,負責端到端的業務功能中的一個環境,因此,需要支持構件的組裝,以形成更大粒度的構件,支撐軟件復用與集成。

開發一個子系統粒度的構件通常是一件很復雜的事情,如CRM,需求瑣碎、變化頻繁、不同客戶要求不盡相同,如果缺乏一個好的支撐平台,人力成本會很高,TTM也會很長,因此,一個好的業務平台,也需要能夠支撐快速的構件開發、定制。

解決構件的組裝和集成,已經有比較成熟的技術了,如ESB、SCA等,IBM、Oracle等大廠商都有提供集成化的開發環境和執行環境。但如何支撐構件的開發這塊,各大廠商也有支撐,比如在展現層,Oracle有ADF,在流程層,IBM和Oracle都提供了BPM,在service層,IBM和Oracle提供了規則引擎,VMWare的Spring,在持久層,Oracle提供了Toplink,還有就JBOSS大名鼎鼎的Hibernate。所有前面提到的這些都是業務無關的技術部件,且各層之間的靠業務開發人員自己來黏合,還是不夠領域化。因此,一個業務平台,僅僅去重復制造IBM、Oracle造過的輪子,是完全沒有競爭力的(這里不算成本)。面向特定領域,評判一個業務平台是否優秀的標准是:

1、是否提供了豐富的領域構件?

2、是否能夠節省業務開發人員黏合各層的工作量?

3、提供了什么樣的機制來應對需求變化?比如有的客戶要求多加個字段、加個校驗,有的客戶要求少個字段、少個校驗等等。

待續。。。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com