如何解決上文提到的鑒定標準中的問題呢？我認為答案就是MDD。
用一個實際的例子來表述一下思路：
在CRM系統有個訂單處理模塊，其提供了訂單管理、訂單流程執行、工單管理等功能，營業員通過界面提交一個訂單請求，如果訂單請求通過業務規則的校驗，則會創建一個訂單對象，訂單對象的創建會觸發訂單流程的創建，訂單流程流轉的過程中，會在各個節點創建工單，也會調用其它子系統開通服務，比如調用物流發貨。訂單流程完成后，訂單對象的狀態也完成。實際的系統比這個要復雜，這里僅僅為了闡述思路，做適當的簡化。
從上面的例子，我們可以識別出幾個模型:訂單、工單、訂單流程，訂單、工單、訂單流程都是stateful的、其state的變更會導致其它對象的狀態變更或者服務的執行。
在展現層，展現各個模型是有章法的，比如創建訂單的界面總是一樣的，處理工單的界面也總是一樣的，展現訂單的界面也總是一樣的。因此，我們可針對指定的對象的某種需要展現的狀態，提供合適的展示構件（WEB TAG）來展示它。
在持久層，因為對象總是持久化到一張表當中的，因此，可用一些ORM的框架來持久化對象，而不是開發人員針對每個場景去寫SQL，復雜的關聯查詢可以使用類HQL。
各對象之間的關聯操作通過事件驅動。
舉一個訂單創建的例子：
1、開發做的工作：
1）使用元數據定義訂單的數據結構，包含持久化元數據、基本屬性元數據、字典元數據；
2）定義訂單狀態機，以及狀態變遷的規則；
3）建模訂單處理流程；
4）定義訂單請求處理規則流，并發布為一個受理訂單請求的服務；
5）開發訂單創建界面，使用訂單WEB構件來展示訂單對象；
6）定義事件，以及事件的監聽服務；
2、系統執行流程：
1）營業員打開訂單創建界面，系統獲取訂單對象的元數據，生成訂單創建頁面；
2）營業員點擊訂單創建界面的提交按鈕，調用受理訂單請求的服務；規則流執行，如果規則校驗錯誤，則返回錯誤，如果成功，則創建訂單，返回成功；
3）因創建訂單，導致訂單的狀態變為創建狀態，觸發訂單創建事件；
4）訂單創建的監聽服務流程服務接收到事件，觸發訂單處理流程的創建；
5）流程執行的過程中編排第三方系統服務；流程執行結束后，觸發訂單流程結束事件，流程結束事件的監聽服務訂單管理接收到事件，觸發狀態機變遷，訂單狀態變為完成。
上述開發做的工作全部可通過配置完成。后續如果增刪字段，修改元數據即可，要增刪改業務規則，調整業務規則即可，要調整實體狀態，修改實體狀態機即可。
業務平臺要致力于對狀態機、業務流程、SEP、元數據、領域化的WEB構件的實現，并將其有機整合。
寫的比較亂，過幾天再整理一下。。。