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