在過去的開發過程中，我發現所謂的業務，在企業級應用的背景下，最終的實現操作都是數據庫的增刪改查，或者說通俗點說都是數據庫的操作，其他的業務類型多多少少是在圍繞數據庫的操作。在用戶的需求最終轉化成設計再到代碼的實現。
我這里說的業務可能是一個有別于技術的東西，有些東西純粹是靠技術來實現的，用戶沒有概念，跟他說也沒有用，比如做接口，你可能用web service 。用TCP通信等等。這些很多是用戶是看不見的。
我認為一個比較理想的業務系統應該是業務駕臨在技術之上，二者相得益彰。技術需要解決的問題是他有一個平臺，能讓業務方便的在這個平臺上實現。所以我們在做架構的時候要分清楚哪些是業務需要解決的問題，哪些是技術需要解決的問題。
從業務的角度看技術，我希望業務能夠非常方便的在這個平臺上實現，不僅如此，我還希望我的業務變更了。能夠以最少的改動或者不改動就能夠實現變更。理想的做法我希望業務都是配置進去的，我在變更的時候只需要修改相應的配置就可以了。當然100%的配置出來也不太現實，據我所知，在sap,siebel里面的報表是必須開發的。因為報表主要是查詢，查詢就非常靈活，單靠配置能難達到目的。
從技術的角度去看業務，再好的技術加上一個不入流的設計，都為成為教科書上一個很好的反面教材。業務人員需要在對業務的把握上設計軟件。
既然要復用，要能夠用配置實現業務，那配置些什么東西了?那些地方可以配置。這個就是框架要做的事情了。說到框架大家最喜歡議論的就是怎么快速實現crud了。畢竟，一個系統的很大部分都是在做這個事情。