搞了近五年的系統開發，總是抱著一種思維模式，使用者的乙個操作對應乙個請求和乙個事務，比如：使用者選擇了n條記錄，我就會向伺服器發生乙個請求，伺服器在乙個事務中進行處理。前幾天在群裡乙個前輩反問：批量操作難道真的要在乙個事務中？這個問題讓陷入了反思，謝謝前輩們（魏瓊東）。
ddd中有聚合的概念，乙個聚合有且只有乙個聚合根和一些其他實體，如：訂單聚合中，訂單是聚合根，訂單明細是聚合內的實體。因為ddd中只能操作聚合根，這篇文章就介紹聚合根的批量刪除問題。有人問聚合內的實體的刪除咋弄？聚合內實體的刪除必須伴隨著聚合根的修改（這裡不做詳細介紹）。
另外一點是需要注意的是，引入工作單元之後，批量操作和單個操作伺服器端的邏輯是不同的，如：索引驗證問題和工號生成問題（這裡不做詳細介紹）。
我目前有三種選擇，我記錄下來，然後乙個乙個分析：
傳送乙個請求，伺服器乙個事務。
傳送乙個請求：伺服器n個事務。
傳送n個請求，伺服器n個事務。
這是我之前採用的思路，現在覺得非常不好，為什麼非要在乙個事務中呢？如果您覺得非要在乙個事務中，就告訴我一聲。
這種思路可以接受，不過要在伺服器端做額外的處理，如：收集哪些失敗或成功的資訊，發生給客戶端，如果我不用ajax，我就會選擇這個方案。
考慮到我是ajax程式設計，這種思路好，重分利用了客戶端。
思路有了，實現就不是問題了，搞個佇列排隊傳送請求就行了，當然你可以選擇並行傳送請求或分批次排隊傳送請求。
1/**2* 刪除功能。3*
4* @class delete56
7*/10requires: [
14],
1516 delete_confirm_title: '刪除確認',
17 delete_confirm_msg: '確定執行刪除嗎？',
1819
defaultconfig: ,
2627/**
28* 契約：
29*
32* @protect
33* @method onclickhandler
34* @param button 按鈕
35*/
36 onclickhandler: function
(button)
4546 ext.msg.confirm(me.delete_confirm_title, me.delete_confirm_msg, function
(btn)
5051
me.deleterecords(records);
52});
53},
5455/**
56* private
57* @method deleterecords
58*/
59 deleterecords: function
(records)
6667
68 success: function
(record) ,
71 failure: function
(record, operation)
74});75}
76 });
1///2
///刪除。
這裡只是演示了批量刪除，有很多針對聚合根的批量操作都可以這麼處理。
危險的DDD聚合根
原文 危險的ddd聚合根 ddd的核心是聚合。這沒有問題，大家都認同。但關於ddd中的聚合方式，其實我還是有些擔心，下面說說我的想法，希望大家參與討論。其實當初第一次看到ddd中關於聚合根部分論述的時候，就感覺有些僵化。ddd中的聚合根的分析設計思路大致是這樣 1 業務本質邏輯分析 2 確認聚合物件...
DDD 子龍關於聚合的總結
聚合的劃分是需要細心設計的，聚合劃分時除了根據聚合本身的定義外還應該能保證聚合內部元素的一致性，當外界通過聚合根對聚合內的元素進行修改時能使改變的元素與其他元素之間保持設定的一致性，確保概念上的不變。聚合設計大多數時候都會受到主觀因素的影響，有的人喜歡設計大聚合 聚合包含的實體和值物件數量太多 因為...
DDD中的聚合和UML中的聚合以及組合的關係
uml 聚合關係 成員物件是整體的一部分，但是成員物件可以脫離整體物件獨立存在。如汽車 car 與引擎 engine 輪胎 wheel 車燈 light 之間的關係為聚合關係，引擎 輪胎 車燈可以脫離車而存在，比如把乙個引擎換到另乙個汽車上也可以。組合關係 也表示的是一種整體和部分的關係，但是在組合...