畢業后，做了很多年的中間件，有工作流，有數據持久層框架，還有個類似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、提供了什么樣的機制來應對需求變化？比如有的客戶要求多加個字段、加個校驗，有的客戶要求少個字段、少個校驗等等。
待續。。。