這是一個講解DDD落地的文章系列，作者是《實現領域驅動設計》的譯者滕雲。本文章系列以一個真實的並已成功上線的軟體項目——碼如雲（https://www.mryqr.com）為例，系統性地講解DDD在落地實施過程中的各種典型實踐，以及在面臨實際業務場景時的諸多取捨。 本系列包含以下文章： DDD入門 ...
這是一個講解DDD落地的文章系列，作者是《實現領域驅動設計》的譯者滕雲。本文章系列以一個真實的並已成功上線的軟體項目——碼如雲（https://www.mryqr.com）為例，系統性地講解DDD在落地實施過程中的各種典型實踐，以及在面臨實際業務場景時的諸多取捨。
本系列包含以下文章：
案例項目介紹
既然DDD是“領域”驅動，那麼我們便不能拋開業務而只講技術，為此讓我們先從業務上瞭解一下貫穿本文章系列的案例項目 —— 碼如雲（不是馬雲，也不是碼雲）。如你已經在本系列的其他文章中瞭解過該案例，可跳過。
碼如雲是一個基於二維碼的一物一碼管理平臺，可以為每一件“物品”生成一個二維碼，並以該二維碼為入口展開對“物品”的相關操作，典型的應用場景包括固定資產管理、設備巡檢以及物品標簽等。
在使用碼如雲時，首先需要創建一個應用(App)，一個應用包含了多個頁面(Page)，也可稱為表單，一個頁面又可以包含多個控制項(Control)，比如單選框控制項。應用創建好後，可在應用下創建多個實例(QR)用於表示被管理的對象（比如機器設備）。每個實例均對應一個二維碼，手機掃碼便可對實例進行相應操作，比如查看實例相關信息或者填寫頁面表單等，對錶單的一次填寫稱為提交(Submission)；更多概念請參考碼如雲術語。
在技術上，碼如雲是一個無代碼平臺，包含了表單引擎、審批流程和數據報表等多個功能模塊。碼如雲全程採用DDD完成開發，其後端技術棧主要有Java、Spring Boot和MongoDB等。
碼如雲的源代碼是開源的，可以通過以下方式訪問：
聚合根與資源庫
在上一篇請求處理流程中我們講到，領域模型是DDD的核心，而聚合根又是領域模型的核心。從某種意義上講，DDD中其它組件均可看作是對聚合根的支撐或輔助。在本文中，我們將對聚合根以及與之密切相關的資源庫(Repository)做詳細的講解。
聚合根是什麼
在DDD概念大白話一文中，我們講到了“什麼是聚合根”，這裡再重覆一下。聚合根中的“聚合”即“高內聚，低耦合”中的“內聚”之意；而“根”則是“根部”的意思，也即聚合根是一種統領式的存在。事實上，並不存在一個教科書式的對聚合根的理論定義，你可以將聚合根理解為一個系統中最重要最顯著的那些名詞，這些名詞是其所在的軟體系統之所以存在的原因。為了給你一個直觀的理解，以下是幾個聚合根的例子：
- 在一個電商系統中，一個訂單（Order）對象表示一個聚合根
- 在一個CRM系統中，一個客戶（Customer）對象表示一個聚合根
- 在一個銀行系統中，一次交易（Transaction）對象表示一個聚合根
你可能會問，軟體中的概念已經很多了，為什麼還要搞出個聚合根的概念？我們認為這裡至少有2點原因：
- 聚合根遵循了軟體中“高內聚，低耦合”的基本原則
- 聚合根體現了一種模塊化的原則，模塊化思想是被各個行業所證明的可以降低系統複雜度的一種思想。所謂的DDD是“軟體核心複雜性應對之道”，也即這個意思，它將軟體系統在人腦中所呈現地更加有序和簡單，讓人可以更好地理解和管控軟體系統。
在實際項目中識別聚合根時，我們需要對業務有深入的瞭解，因為只有這樣你才知道到底哪些業務邏輯是內聚在一起的。這也是我們一直建議程式員和架構師們不要一味地埋頭於技術而要多關註業務的原因。
事實上，如果讓一個從來沒有接觸過DDD的人來建模，十有八九也能設計出上面的訂單、客戶和交易對象出來。沒錯，DDD絕非什麼顛覆式的發明，依然只是在前人基礎上的一種進步而已，這種進步更多的體現在一些設計原則上，對此我們將在下文進行詳細闡述。
聚合根基類
在代碼實現層面，一般的實踐是將所有的聚合根都繼承自一個公共基類AggregateRoot：
//AggregateRoot
@Getter
public abstract class AggregateRoot implements Identified {
private String id;//聚合根ID
private String tenantId;//租戶ID
private Instant createdAt;//創建時間
private String createdBy;//創建人的MemberId
private String creator;//創建人姓名
private Instant updatedAt;//更新時間
private String updatedBy;//更新人MemberId
private String updater;//更新人姓名
private List<DomainEvent> events;//臨時存放領域事件
private LinkedList<OpsLog> opsLogs;//操作日誌
@Version
@Getter(PRIVATE)
private Long _version;//版本號，實現樂觀鎖
//...此處省略了AggregateRoot中行為方法
@Override
public String getIdentifier() {
return id;
}
}在AggregateRoot中，包含聚合根ID（id）、創建信息(createdAt和createdBy)和更新信息（updatedAt和updatedBy）等數據。租戶ID（tenantId）用於標定聚合根所在的租戶（碼如雲是一個多租戶系統）。另外，events用於臨時性存放聚合根中所產生的領域事件，我們將在領域事件一文中對此所詳細解釋。
實際的聚合根繼承自AggregateRoot，例如，在碼如雲中，分組（Group）聚合根的實現如下：
@Getter
@Document(GROUP_COLLECTION)
@TypeAlias(GROUP_COLLECTION)
@NoArgsConstructor(access = PRIVATE)
public class Group extends AggregateRoot {
private String name;//名稱
private String appId;//所在的app
private List<String> managers;//管理員
private List<String> members;//普通成員
private boolean archived;//是否歸檔
private String customId;//自定義編號
private boolean active;//是否啟用
private String departmentId;//由哪個部門同步而來
//...此處省略了Group的行為方法
}聚合根基本原則
從上面的代碼例子可以看出，聚合根只是普通的Java對象而已，真正使之成為聚合根的是一些特定的設計原則。
內聚性原則
這個原則不用我們再細講了吧，估計你在大學里就學過，只舉個例子，對於上面的分組Group對象來說，管理員managers、普通成員members以及啟用標誌active均是Group不可分割的屬性，這些屬性獨立於Group是無法存在的。
對外黑盒原則
對外黑盒原則講的是，聚合根的外部（也即聚合根的調用方或客戶方）不需要關心聚合根內部的實現細節，而只需要通過調用聚合根向外界暴露的共有業務方法即可。具體表現為，外部對聚合根的調用只能通過根對象完成，而不能調用聚合根內部對象上的方法。舉個例子，在碼如雲中，管理員可以向分組(Group)中添加成員，具體的實現代碼如下：
//Group
public void addMembers(List<String> memberIds, User user) {
if (isSynced()) {
throw new MryException(GROUP_SYNCED,
"無法添加成員，已設置從部門同步。",
"groupId", this.getId());
}
this.members = concat(members.stream(), memberIds.stream())
.distinct()
.collect(toImmutableList());
addOpsLog("設置成員", user);
}這裡，外部在向分組中添加成員時，需要調用Group上的addMembers()方法，該方法知道將memberIds添加到自身的members欄位中，這個過程對外部是不可見的。與之相對的另一種方式是，外部調用法先拿到Member的members引用，然後由外部自行向members中添加memberIds：
//外部調用方
@Transactional
public void addGroupMembers(String groupId, List<String> memberIds, User user) {
Group group = groupRepository.byIdAndCheckTenantShip(groupId, user);
if (group.isSynced()) {
throw new MryException(GROUP_SYNCED,
"無法添加成員，已設置從部門同步。",
"groupId", group.getId());
}
List<String> members = group.getMembers();
members.addAll(memberIds);
groupRepository.save(group);
log.info("Added members{} to group[{}].", memberIds, groupId);
}這種方式是一種反模式，存在以下缺點：
- 外部需要瞭解
Group的內部結構，背離了對外黑盒原則，本例中，外部通過group.getMembers()獲取到了Group內部的members屬性 - 聚合根內部的業務邏輯泄漏到了外部，背離了內聚性原則，本例中，對
group.isSynced()的調用原本應該放在Group中的，結果卻由外部承擔了該職責
在對外黑盒原則的指導下，聚合根自然形成了一個邊界，它站在這個邊界上向外聲明：“我所包圍著的內部的所有均由我負責，如果誰想訪問我的內部，直接訪問是被禁止的，只能通過我這個“根”來訪問。”
不變條件原則
不變條件(Invariants)表示聚合根需要保證其內部在任何時候均處於一種合法的狀態（也即數據一致性需要得到保證），一個常見的例子是訂單(Order)中有訂單項(OrderItem)和訂單價格(Price)，當訂單項發生變化時，其價格應該隨之發生變化，並且這兩種變化應該在訂單的同一個業務方法中完成。這一點是好理解的，既然聚合根對外是一個黑盒，那麼外界便不會負責給你聚合根擦屁股，你聚合根自己需要保證自身的正確性。
在碼如雲中，應用管理員可以向分組(Group)中添加分組管理員。這其中有層隱含意思是，既然分組管理員也是分組成員，那麼在添加分組管理員的同時需要一併將其添加到分組成員中，具體實現代碼如下：
//Group
public void addManager(String memberId, User user) {
if (!this.members.contains(memberId)) {
this.members = concat(members.stream(), Stream.of(memberId))
.distinct()
.collect(toImmutableList());
}
this.managers = concat(this.managers.stream(), Stream.of(memberId))
.distinct()
.collect(toImmutableList());
raiseEvent(new GroupManagersChangedEvent(this.getId(), this.getAppId(), user));
addOpsLog("添加管理員", user);
}在本例的添加分組管理員addManager()方法中，我們除了向managers中添加成員外，還保證了該成員也出現在members中。這裡的“分組管理員也是分組成員”即是一種不變條件，我們需要在聚合根內部保證不變條件不被破壞，因為不變條件往往意味著核心的業務邏輯。
通過ID引用其他聚合根原則
當一個聚合根需要引用另一個聚合根時，並不需要維持對另一聚合根的整體引用，而是只需通過ID進行引用即可。這個原則的出發點是：聚合根和聚合根之間是一種平級關係，並不是隸屬關係，每個聚合根本身是一個相對獨立的模塊，其與其他聚合根的關係應該通過ID這種松耦合的方式進行引用，如果整體引用則更像是一種包含關係。
在碼如雲中，分組(Group)通過appId引用其所屬的應用(App)，通過departmentId引用所同步的部門(Department)，而在managers和members欄位中，則是以memberId引用相應成員(Member)：
@Getter
@Document(GROUP_COLLECTION)
@TypeAlias(GROUP_COLLECTION)
@NoArgsConstructor(access = PRIVATE)
public class Group extends AggregateRoot {
private String name;//名稱
private String appId;//所在的app
private List<String> managers;//管理員
private List<String> members;//普通成員
private boolean archived;//是否歸檔
private String customId;//自定義編號
private boolean active;//是否啟用
private String departmentId;//由哪個部門同步而來
//...省略其他代碼
}與基礎設施無關原則
既然整個領域模型與基礎設施無關，那麼位於領域模型之內的聚合根自然也不能與基礎設施相關，這樣好處是將業務複雜度與技術複雜度解耦開來，讓業務模型可以獨立於技術設施而完成自身的演變。比如，假設一個項目需要從Spring框架遷移到Guice框架，此時如果能夠保證領域模型與基礎設施的無關性，那麼對領域模型的遷移過程講變得非常簡單，基本上無需修改任何代碼直接拷貝到新的項目中即可。
事實上，碼如雲尚未完全做到這一點，從上面的例子中可以看到，AggregateRoot和Group對Spring框架中的@Version、@Document和@TypeAlias3個與持久化相關的註解存在引用。如需解決這個問題，可以考慮在領域模型之外另建專門用於資料庫訪問的持久化對象(Persistence Model)。但是，引入持久化對象是有成本的，比如需要維護領域對象與持久化對象之間的相互轉化等。在碼如雲，我們選擇了妥協，一方面考慮到持久化對象的成本，另一方面我們也預見在將來要遷移出Spring框架的幾率是非常小的。不過，除了前面提到的3個註解之外，碼如雲中的聚合根可以做到對基礎設施沒有任何其他引用。關於持久化對象，在Stackoverflow上有過非常有意義的討論，讀者可自行閱覽。
跨聚合根用例
通常來講，一個業務用例只會操作一個（或一種）聚合根。但有時，一個業務用例可能會導致多個（或多種）聚合根對象的更新，此時可分兩種情況：
- 如果聚合根位於不同的進程空間（比如不同的微服務）中，那麼解決方式一是可以使用事件驅動架構(EDA)，二是通過全局事務（比如JTA）完成。基於全局事務的性能和效率低下等問題，DDD社區一般建議採用事件驅動架構，即在一個進程空間中只對其包含的聚合根進行操作，然後通過向其他進程空間發送事件通知的方式，使得其他進程空間做相應的聚合根更新。
- 如果聚合根位於同一個進程空間，此時依然可以選擇事件驅動架構，但是另一種更簡單實用的方式是直接同時更新多個聚合根，畢竟此時對所有聚合根的更新均處於同一個本地事務中。
碼如雲是一個單體系統，因此屬於以上的第2種情況，我們根據聚合根之間的業務緊密程度的不同，在有些場景下選擇了同時更新多個聚合根，在另一些場景下則選擇通過事件驅動機制解決。比如，在“創建實例”的用例中，除了創建實例(QR)之外，還需要創建該實例對應的碼牌(Plate)，由於“有實例就必有碼牌”，因此它們之間是緊密聯繫的，故在碼如雲中我們選擇了在同一個本地事務中同時更新實例和碼牌：
//QrCommandService
@Transactional
public CreateQrResponse createQr(CreateQrCommand command, User user) {
String name = command.getName();
String groupId = command.getGroupId();
Group group = groupRepository.cachedByIdAndCheckTenantShip(groupId, user);
String appId = group.getAppId();
App app = appRepository.cachedById(appId);
PlatedQr platedQr = qrFactory.createPlatedQr(name, group, app, user);
QR qr = platedQr.getQr();
Plate plate = platedQr.getPlate();
//同時保存QR和Plate
qrRepository.save(qr);
plateRepository.save(plate);
log.info("Created qr[{}] of group[{}] of app[{}].",
qr.getId(), groupId, appId);
return CreateQrResponse.builder()
.qrId(qr.getId())
.plateId(plate.getId())
.groupId(groupId)
.appId(appId)
.build();
}可以看到，在用例方法createQr()中，我們先後調用qrRepository.save(qr)和plateRepository.save(plate)分別完成了對QR和Plate的持久化。
如果你希望瞭解事件驅動架構相關的知識，請參考本系列的領域事件一文。
資源庫
在DDD中，資源庫(Repository)以聚合根為單位完成對資料庫的訪問。這裡的重點是“以聚合根為單位”，也即只有聚合根才配得上擁有資源庫（畢竟在DDD中大家都是圍繞著聚合根轉的嘛），其他對象（比如非聚合根實體）是沒有對應資源庫的，這也是資源庫和DAO最大的區別。在編碼實現時，資源庫方法所接受的參數和返回的數據都應該是聚合根對象，例如，在碼如雲中，成員(Member)聚合根對應的資源庫定義如下：
public interface MemberRepository {
Member byId(String id); //返回聚合根
Optional<Member> byIdOptional(String id); //返回聚合根
Member byIdAndCheckTenantShip(String id, User user); //返回聚合根
void save(Member member); //聚合根作為參數
void delete(Member member); //聚合根作為參數
}行業中這麼一個現象，很多程式員在面對一個新的業務需求時，首先想到的是如何設計資料庫的表結構，然後再編寫業務代碼。在DDD中，這是一種反模式，既然是“領域驅動”，那麼我們首先應該關心的是如何業務建模，而不是資料庫建模。事實上，正如Robert C. Martin在《整潔架構》一書中所說，資料庫只是一個實現細節而已，不應該成為軟體建模的主體。
資源庫的作用，在於它在業務複雜度和技術複雜度之間做了一層很好的隔離，讓我們可以獨立地看待軟體的業務模型而不受技術設施的影響。從本質上講，資源庫做的事情只是實現數據在記憶體和磁碟之間相互傳輸而已。在編程實現業務邏輯的時候，我們只需關心記憶體中的那個聚合根對象即可，當聚合根對象的狀態由於業務操作發生了改變之後，再調用資源庫將新的聚合根狀態同步到磁碟中完成持久化，在調用時我們假設並相信資源庫一定可以完成其自身的使命。
@Transactional
public void addGroupManager(String groupId, String memberId, User user) {
Group group = groupRepository.byIdAndCheckTenantShip(groupId, user);
group.addManager(memberId, user);
groupRepository.save(group);
log.info("Added manager[{}] to group[{}].", memberId, groupId);
}在上例的“向分組中添加管理員”用例中，首先通過資源庫GroupRepository的byIdAndCheckTenantShip()方法得到聚合根Group對象，然後再完成後續操作。這裡的addGroupManager()無需知道Group是如何載入的，甚至不用知道後臺使用的是MySQL還是MongoDB或是其他，反正通過調用GroupRepository.byIdAndCheckTenantShip()可以得到一個完整合法的Group對象即可。
在資源庫中，最重要的方法有以下3個：
public interface GroupRepository {
Group byId(String id);
void save(Group group);
void delete(Group group);
}其中，byId()用於根據ID獲取指定聚合根，save()用於保存聚合根，delete()則用於刪除聚合根。除此之外，資源庫中還可以包含更多的查詢方法，比如在GroupRepository中還包含以下方法：
//根據部門ID查找分組
List<Group> byDepartmentId(String departmentId);
//根據ID查找分組，返回Optional
Optional<Group> byIdOptional(String id);
//根據ID查找分組，同時檢查租戶
Group byIdAndCheckTenantShip(String id, User user);需要註意的是，這裡的查詢方法指的是在實現業務邏輯的過程中需要做的查詢操作，並不是為了前端顯示那種純粹的查詢，因為純粹的查詢操作不見得一定要放到資源庫中，而是可以作為一個單獨的關註點通過CQRS解決。
在DDD項目中，通常將資源庫分為介面類和實現類，將介面類放置在領域模型domain包中，而將實現類放置在基礎設施infrastructure包中，這種做法有2點好處：
- 通過依賴反轉，使得領域模型不依賴於基礎設施
- 實現資源庫的可插拔性，比如未來需要從MongoDB遷移到MySQL，那麼只需創建新的實現類即可
總結
在本文中，我們講到了作為DDD核心的聚合根的設計原則及實現，其中包含內聚原則、對外黑盒原則和不變條件原則等。此外，我們也對與聚合根密切相關的資源庫做了講解。在下一篇實體與值對象中，我們將講到實體和值對象之間的區別，以及各自的典型編碼實踐。
