不想只做Cruder？實體、聚合根，還不快去了解下

說到唯一標識，我們很容易聯想到資料庫表裡的唯一主鍵，認業務的唯一標識就是表記錄裡的id列，其實這種理解是不太全面的。

資料表裡的主鍵 id 在某些情況下，可以作為實體的唯一標識，但兩者本身屬於不同的概念。

還是以 Order 實體為例，它在資料庫中可能存在類似下面這樣的一張表：

那麼，這裡的 id 只是資料庫表裡的一個主鍵，而 order_id 才是 Order 這個領域實體的唯一標識。

再來看一個 Product 的例子，它的定義比較簡單：

products 表有一個 id 列作為主鍵，同時，我們通常也會將這個 id 作為 Product 實體的唯一標識。也就是說，資料庫表的主鍵，有的時候可以作為唯一標識使用，有的時候卻不可以。

總之，我們只需要記住， 唯一標識和資料庫結構沒有關係，主鍵 id 是儲存層面的唯一標識，而業務層面的唯一標識才是實體關心的。

03 ⎪   如何表示唯一標識

上面提到的產品ID，是一個不需要使用值物件做唯一標識的例子。

Product 實體用自增 ID 來代表唯一標識，這個 ID 除了能唯一標識一個產品外，沒有其他任何與之相關的行為。 

所以這裡可以將其簡化成一個 int64 型別。int64 也是不可變的，因此其本質上也是符合值物件的特點的。

這種實現方式的缺點是表達能力不強，但好在足夠簡單。

綜合來看： 

這種情況依賴使用者的輸入，使用者需要保證輸入的唯一標識真的是唯一的，這通常很難。但是，在某些特殊場景下還是可以做到的。

比如在學校圖書館，管理員錄入書本的場景。

我們知道每本書都有一個 ISBN 碼，這個 ISBN 碼就可以作為書本的唯一標識。管理員在錄入書本時，用手持裝置直接掃描 ISBN 碼，這個掃描到的 ISBN 碼，就可以認為是使用者直接傳入的唯一標識。

大部分情況下，我們遵循的都是這種方法。無論是上面提到的 OrderId 還是 ProductId，雖然生成的方式不同，但都可以歸屬到系統生成的範疇。

這裡面有一種比較特殊的情況，是使用資料庫的自增來生成。

這種情況特殊的點在於，實體建立好了之後，可能還沒有來得及分配一個唯一標識，因為此時實體還沒有進行持久化。

沒有唯一標識的實體，可能需要面對下面兩個問題：

  如果需要釋出領域事件，這個時候因為還沒生成唯一標識，事件接收者無法知道是哪個實體發出的事件；

說到這，你可能會問了，那怎麼解決這個問題呢？辦法是有，就是將唯一標識的生成提前， 在實體建立好的時候，保證一定是有唯一標識的。

通常，我們會在 Repository 介面中，定義一個 NextIdentity 方法，如下：

注：Repository 對應的是 DDD 裡的倉儲概念，我們在後面的章節會介紹。

而需要用到這個 NextIdentity 方法的地方，一般是在工廠或應用服務裡。

注：工廠和應用服務也是 DDD 裡的概念，同樣放在後面的章節進行介紹。

對於應用服務，基本都需要持有一個對應的 Repository 屬性，比如這樣：

而如果是在工廠裡，就要展開討論了。

如果工廠是無狀態的，也可以讓工廠直接持有對應 Repository 屬性，實現方式跟在應用服務裡類似。

如果工廠是有狀態的，那麼只能每次前都建立一個工廠的例項，在建立的時候將 Repository 作為引數傳入：

無論是哪種形式，都需要先生成唯一標識，再生成實體。

聚合，是 DDD 中較為難以理解的一個概念。

很多剛剛接觸 DDD 的同學，常犯的錯誤是設計出一個囊括天地萬物的大聚合。這在戰略設計階段往往看不出什麼問題，但是一旦要落實到程式碼層面，就會發現根本行不通。

當然，我們這裡也不會過多去講應該如何設計聚合，這不是這篇文章的重點。

但是，我們至少要知道，設計小聚合是很重要的一條原則。

小聚合的前提，是要保證聚合內的一致性條件不被破壞。這裡有篇文章可以幫助大家更好的理解，得空了可以看下。（）

更多的原則，還可參考這裡：（https://weread.qq.com/web/reader/f5032ce071fd5a64f50b0f6kad63251024aad61ab143c7e）

當我們迴歸到小聚合的設計後，就會發現，聚合根的實現方式跟實體是非常類似的。

還是考慮 Product 這個例子：

假如說我們的產品模型非常簡單，只有前面的四個屬性，我們是否還有必要再單獨定義一個 ProductAggregate 結構體做聚合根呢？

上面這個寫法顯然是多餘的，Product 是實體，但是，如果在聚合根裡只包含實體一個屬性時，Product 本身也可以當作聚合根來用。

同理，可以推廣到稍複雜的情況。

比如在一個訂單中，通常會包含總價、支付方式、訂單項、地址等內容，如果我們強制區分實體和聚合根的話，可能會寫出如下的程式碼：

但在實際開發中，可以在 Order 中直接引用 OrderItem，這樣就省去了對 OrderAggregate 的維護，Order 也變成了實體加聚合根的雙重身份：

同時，我們建議所有的聚合根在命名上都加一個 Aggregate 或 Agg 的字尾，用以明確地表示這是一個聚合根。

使用聚合根時，還有一個經常容易犯的錯誤，就是在一個聚合根中引用了另外一個聚合根。

正確的做法是 透過全域性唯一標識來引用外部的聚合。

原因就在於，在一個事務中，原則上只能修改一個聚合，如果不持有對其他物件的引用，也就避免了對這個物件的修改。

在你的程式碼裡，如果一個事務必須要修改多個聚合，這個時候就要考慮聚合設計的是否合理，這種情況通常意味著聚合的一致性邊界是錯誤的。

▶︎  延伸思考