上一篇文章講了repository的實現。結合前面的文章基本把ddd戰術篇中的登場人物都介紹了一遍。依次是如下幾個角色。
首先是位於domain層的domain objects
- aggregate
- entity
- value object
- domain service
- repository
- specification
- factory
另外有還有兩種service。application service, infrastructure service.
當我們分析業務，實際建模時，最重要的當然是aggregate, entity與value object。
我們會將業務邏輯儘量寫進entity與value object。
而aggregate還有確保資料完整性的責任。entity，value object也最終隸屬於某個aggregate。（value object如果不需要永久化的話，那它可以獨立於aggregate）
因此aggregate的設計是十分重要的，這篇文章就來談談aggregate的設計策略。

儘量設計小aggregate？

什麼是小aggregate？
那我們先看看什麼是大的吧～

如果所示，root entity直接引用了很多的entity。
我們用例子來說明一下。假設我們對處理一個教室物品管理的問題。教室裡有椅子，桌子和黑板這些物品，為了解釋資料完整性的問題，假設一個教室裡不能有超過50樣物品。另一個需求是假設這些物品需要維護，要記錄各個物品是在何時維護的。
大概是這麼一個關係

比較直觀的方案當然是把教室當作一個aggregate，裡邊有它的物品。
首先是教室類，他是一個entity

public class Classroom {
  private
 
 ClassroomId classroomId;
  private String classRoomNo; // eg: 402
  private List<Item> items;

  public Item add(Item item) throws ItemLimitExceededException {
    if(items.size() == 50) {
      throw new ItemLimitExceededException();
    }
    item.add(item);
  }

  public Item findItem(ItemId itemId){
  items.toStream().filter(item -> item.getItemId() == itemId).findFirst().getOrElse( null
 
 );
  }
}

通過在add()方法中增加檢驗來保證資料完整性。
物品類（椅子，桌子，黑板什麼的）

@Getter
public class Item {
  private ItemId itemId;
  private ItemType itemType;
  private Date maintenanceDate;
  public void maintain(){
    maintenanceDate = DateUtils.now(); // 更新檢測日
  }
}

public enum ItemType {
  Chair, Desk, Blackboard
}

需不需要具體的Desk，Chair，Blackboard類還是隻要Item一個類就夠了是可以討論的問題，不過現在我們關注的不是這個，而是Classroom這個aggregate。當我們一這個方式實現時，我們獲取Classroom的引用時，必然會把它所包含的物品一起獲取。
想象一下ClassroomRepository的實現，獲得某一個id的Classroom。不僅要讀取classroom,我們不得不也把所有的物品items也一起讀取。這個是個比較低效的做法的。
另外，按照這樣的做法，如果你對某一個教室進行更新時，還會更新它所包含的物品。比如當你需要更改教室的名字，明明是和椅子，桌子無關的處理，但也必須去更新他們。這樣的更新範圍較大，當這個系統需要管理的東西變得十分龐大，併發處理很多時，容易導致鎖問題的出現，造成更新的失敗。（當然現實可能是這個系統永遠不會變得那麼大，難道這麼一個管理系統會指望同時線上使用者數億？我承認這個例子是在是太不合適勒orz,不過意思能傳達就好了…早知道該用論壇什麼的做例子！）
此外，因為ddd的aggregate思想的一些限制，位於某一個aggregate內的entity，你必須通過它的root entity才能獲取的。在這個例子中即你要獲得一張Chair的引用，你必須先獲得它所在Classroom的引用才行。Chair不是root aggregate，它沒有repository，所以也不存在跳過Classroom的作弊方式。那這會有什麼問題呢。假設我們需要維修了一張Chair。記錄他的維護時間。

 chair.maintain();

大概會是相面這個樣子

  Classroom classroom = classroomRepository.findOne(new ClassroomSpecificationById(classroomId);
  Item chair = classroom.findItem(chairId);
  chair.maintain();

為了呼叫一張Item椅子的方法，我們必須把Classroom讀取出，連帶一群我們根本不在意的Desk，Chair。這樣的做法超級低效，在高併發情況下，會有更新失敗就更容易發生（這樣使用者體驗會很差哦！如果你這麼幹，你就等著和產品經理或者設計師單挑吧！或者你是被群毆的那位！）
那如果不把所有object都扔進一個aggregate，怎麼辦。那就拆分成好幾個aggregate。把物品Item也作為aggregate。

@Getter
public class Item {
  private ItemId itemId;
  private ItemType itemType;
  private Date maintenanceDate;
  public void maintain(){
    maintenanceDate = DateUtils.now(); // 更新檢測日
  }
}

其實Item本身的實現沒有什麼變化啦～
接著是教室類

public class Classroom {
  private ClassroomId classroomId;
  private String classRoomNo; // eg: 402
  private List<ItemId> itemIds;

  public Item add(ItemId itemId) throws ItemLimitExceededException {
    if(itemIds.size() == 50) {
      throw new ItemLimitExceededException();
    }
    itemIds.add(itemId);
  }
}

aggregate之間的引用，在ddd中是通過id引用的。例子中Classroom這個aggregate是持有的Item的root aggregate的id（好繞口）來表示Classroom與Item的包含關係的。
按照這樣的設計，Item可以有自己的repository,你可以不通過Classroom對某個Item進行操作。

  Item item = itemRepository.find(new ItemSpecification(itemId));
  item.maintain();

當然你也必須放棄一個功能，便是從Classroom這個aggregate中直接獲取某個Item引用的功能。findItem()這個方法就實現不了啦。
* 我見過一些裡類似於在entity 中放入repository的做法。比如像下面這樣。

public class Classroom {
  private ItemRespository itemRepository;

  public Item findItem(ItemId itemId) {
    return itemRepository.findOne(new ItemSpecificationById(itemId));
  }
}

個人不是很推薦這種做法。因為entity依賴於外部的repository。另外repository是無狀態的，和entity不太般配～
歸納一下
大aggregate的缺點。
1. 從aggregate的角度來說，每次獲得一個aggregate的引用會讀取過多的資料
2. 從aggregate的子entity的角度來說，所有的操作都必須經過root entity，如果對子entity的操作可能影響資料完整性，這種方式是可行的。反之，這樣的方式便是很笨拙的。
3. 在高併發情況下，容易出現鎖問題。
大aggregate的優點
1. 更好的維護資料完整性

大aggregate的用處

前面總結了大aggregate在維護資料完整性上是有優勢的。但上面例子中的資料完整性即Classroom最多有50個物品，我們可以用小aggregate的方式來實現，所以我們傾向使用小aggregate。
如果我們的系統需求是不一樣的，比如我們要記錄教室中的物品位置，同時要保證相同位置上不能有兩個物品（資料完整性！）。那麼我們的模型就會發生變化。

@Getter
public class Item {
  private ItemId itemId;
  private ItemType itemType;
  private Position position;
  private maintenanceDate;
  public void maintain(){
    maintenanceDate = DateUtils.now(); // 更新檢測日
  }
}

@Value
public class Position {
  private Integer x;
  private Integer y;
}

當我們要向教室裡加物品時，小aggregate的設計就滿足不了需求了，於是我們可能不得不啟用大aggregate的設計。

public class Classroom {
  private ClassroomId classroomId;
  private String classRoomNo; // eg: 402
  private List<Item> items;

  public Item add(Item item) throws ItemLimitExceededException, PositionOccupiedException {
    if(items.size() == 50) {
      throw new ItemLimitExceededException();
    }
    if(isOccupied(item.getPosition())) {
      throw new PositionOccupiedException();
    }
    item.add(item);
  }

  private boolean isOccupied(Position position) {
    return items.toStream().map(Item::getPosition)
      .anyMatch(p -> p.equals(position));
  }

  public Item findItem(ItemId itemId){
  items.toStream().filter(item -> item.getItemId() == itemId).findFirst().getOrElse( null );
  }
}

總結

這次我們講了一下aggregate的設計策略。討論了大aggregate的優與劣。這部分的理論主要參考《實踐ddd》，作者是提倡使用小aggregate的。個人認為，選擇哪個策略歸根到底會是兩個問題。
1. 權衡資料完整性和抗併發的問題
2. aggregate的非root子entity是否擁有相當多的獨立業務邏輯
根據上邊的原則可以幫助我們決定aggregate的設計。