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