codechris

1.支持多數據庫
應該有一套專門的數據建模和數據持久層機制。整個系統靈活的支持當前主流的數據庫，盡量不使用存儲過程和一些數據庫的特有功能。但后期的數據庫的調優可以通過人工來進行。
對多數據庫的支持不應該引起系統性能的明顯降低，快速平臺應考慮這一問題。

2.支持現在流行的Java和DotNet兩大主流平臺
RapidDev的建模這塊仍然應該遵循MDA的從PIM到PSM的思路進行，模型的建立的第一層應該是跟語言和平臺無關的。只有模型建立具備了邏輯的完整性和正確性則可以翻譯成不同的語言，只是不同的語言可以采用不同的技術來實現。
語言是一個層次的內容，另外是系統架構應該支持多種模式，可以選擇簡單易用的架構，也可以選擇較為復雜的企業級應用架構。

3.對分布式體系結構的支持
RapidDev平臺應該支持CS，BS和多層分布式等多種體系結構。
快速平臺應該支持主流的DCOM，EJB，Web Service和Remoting等分布式技術，并可以靈活配置和選擇。
數據交互應該采用能夠跨應用和平臺的標準協議如SOAP，XML，XSD，WSDL等。

4.開放性和封閉性
遵從開放封閉原則，支持功能的擴展和外部接口的開放。
RapidDev的建模應該是自成一套體系，包括數據建模，對象建模，流程建模，權限建模，操作建模，業務規則建模，界面建模，報表建模等多個業務功能的建模。相關建模間應該盡量抽象出接口，完全通過接口進行關聯和組裝。
RaplidDev應該提供獨立的建模工具，并支持自定義腳本的擴展。
對于同外部系統的EAI集成，應該支持標準的一些服務接口定義，如通過Web Service進行。

5.業務對象，流程，規則驅動的新開發方法論
建模過程應該以業務對象，業務流程和業務規則三者來驅動的。
業務建模關注的是真正實際的業務對象如訂單，變更單等；業務對象在經過實體關系和規范化的分析和解釋后轉變為實際的數據對象和數據表。
流程建模關注的是整個具體的業務流程，流程建模中會直接關聯到系統的權限設置和建模。流程建模最終通過系統工作流引擎實現。
規則建模定制業務對象的操作規則，支持相關的自定義腳本，業務規則的定義最終體現到系統的業務邏輯層。

另外RapidDev平臺必須清晰的體現分析和設計的過程在平臺中，現在常見的一些快速開發平臺的問題點都在于只能處理簡單的問題，而對較為復雜的系統無能為力。因此整個平臺需要將分析和設計過程融合進去，支持對復雜系統的逐步求解和細化。