關於聚合設計與cqrs

記得在去年的時候，也就是14年下半年的時候，那個時候第一次系統得學習領域驅動設計。在此以前，從《企業應用架構模式》中對領域驅動的設計，有所耳聞，並本身瞎摸索實踐了，有大概一年。

後來，啃《領域驅動設計》一書，對其中的構件有了一些系統的瞭解，可是，仍然缺少經驗。當時，用面向對象設計的原則來劃分聚合，用四分法來劃分聚合，查cqrs，其實都感受有些無力。通過兩三個小項目的磨合，對其中的一些坑和原則，已有一些體會。直到後來，啃了《實現領域驅動設計》。書中對各類設計進行了至關詳細的描述，並有代碼示例，可是，卻以爲書中說的並不盡然。此時，咱們已經對領域驅動設計，其中構件的使用，有了至關的本身的理解。可是，總以爲哪裏味道不對。

記得曾經查cqrs架構時，查到一個架構用二進制序列化對象，嚴格得僅用ID進行聚合加載。當時，咱們其實很想用這個架構，可是，存在兩個問題。

一、若是聚合結構變了，數據怎麼處理

二、若是我想經過非ID查詢聚合怎麼處理

其實，主要矛盾仍是第一條。

當時，咱們還在用c#，看似，這個問題是無解的，因此就沒有繼續了。

這個問題，一直困擾我到了今天。

而，就在今天，忽然想到，聚合，爲何會變。聚合，是用來執行業務的。業務的執行，在聚合中，引起，聚合的變化，而全部的查詢數據，均和聚合結構無關。

因此，當聚合的職責，足夠單一，它基本上是不會發生變化的。

而，當咱們想要加什麼東西時，會作的，是增長聚合，須要改變業務時，要作的，是修改領域服務，聚合，是至關穩定的存在。

因此，《實現領域驅動設計》中，纔會推薦在一個事務中僅操做一個聚合吧。由於，聚合，支撐業務操做，其餘操做都會用領域事件觸發。

而反思這點，全部的查詢，均使用領域事件同步的數據，業務數據不可被查詢，僅可被當作聚合，在聚合被加載的時候使用

那麼彷佛，咱們的架構，在向純粹的cqrs方向發展。

來自爲知筆記(Wiz)