Domain Model 再再重新設計其實這種設計某種意義上也沒有什么問題，至少在短消息系統中，因為發消息本身就是用戶的一種行為，但是如果仔細一想就會覺得有些別扭，首先賬戶轉賬業務流程和發消息業務流程雖然表面上相似，但是其聚合的對象并不相同，比如賬戶轉賬示例中，聚合的是賬戶，發消息業務場景中如果這樣分析應該聚合的是用戶，但是很顯然并不是，聚合的是消息對象，如果聚合用戶就會變成用戶消息系統了，這就偏離了大方向，并不是我們所想看到的。還有就是現在的這種設計只適用于短消息業務場景，在郵件和短信業務場景中并不適用，為什么？因為郵件發送和短信發送并不存在用戶的概念（這個用戶概念并不是現實生活中的人，而是系統中的用戶，這個觀點很容易造成誤解），有的只是一個標識（電子郵件或手機號），用來體現出發件人和收件人的概念，也就是說這種標識并不是一個對象（沒有行為的對象），準確的來說應該不是一個實體，那是什么？在領域驅動設計中設計為值對象（為什么要設計成值對象，后面領域模型設計中進行說明），一個沒有行為的對象中加入行為操作，本身邏輯就存在問題，企業宣傳片制作所以這種設計是有問題的。回到發消息這個業務用例上，一個消息對象存在意義的前提是擁有標題、內容、發送人（標識）和接收人（標識），當然還存在一些選填元素，但是主要包含這四個元素，缺少任何一種，就不是一個完整的消息對象，也就是說不能用來發送。發送操作不僅僅是一個對象的行為，而應該是消息領域模型提供的一種服務，也就是領域服務，提供各種消息發送的服務，這一點很容易和基礎層的消息發送服務搞混，區分他們只需要記住一點：基礎層是技術上的實現，領域是業務上的抽象，因為這個業務場景是消息系統，那發消息就是一種業務用例，怎樣拍照才最美 怎樣為女性拍攝好倩影，而并不是一個技術調用方法。說了這么多，總結一下所描述的消息業務場景：抽象所有消息業務邏輯（包含短消息、公司宣傳片拍攝郵件和短信等），應用具體的業務場景（比如短消息）。發消息業務用例：發送人（系統用戶）填寫消息，包含標題、內容、公司宣傳片拍攝發送人（標識）、接收人（標識），調用（應用層發送請求）服務（領域服務）發送消息，相當于郵遞員投遞信件，就是這樣的一個過程，至少聽起來這么簡單，實現起來呢？我覺得那是另一方面的問題了，呵呵。回顧之前領域模型的設計，你會發現完全是一套一套的，也就是說差別很大，造成這種設計的主要原因是領域模型中的邊界和職責問題，這也是領域模型設計中最難的一點，如果邊界確定和職責分配和上一版本有細微的差別，那設計出來的領域模型會和上一版本完全不一樣，就比如用戶的邊界確定（是實體？還是值對象？），還有就是倉儲的職責問題（領域還是應用層？），如果不確定這些因素，設計出來的領域模型就不是真正的領域模型。那為什么要把發送人（標識）或接收人（標識）設計成值對象？那我們分析一下消息系統中收發件人，首先需要明確一點的就是，我們設計的是消息系統，并非是用戶消息系統，也就是說把用戶中的行為剔除掉（SendMessage 和 ReceiveMessage），對象除掉行為之后就只有屬性了，如果一個實體中只有屬性，是不是所必要的呢？對于消息系統而言，用戶是不被存儲的，也就是說用戶只是在消息系統中作為一個標識，所謂標識就是所表現出來的一個值。在短消息業務場景中也是類似，因為短消息系統中的用戶概念來自于其他系統，那其他系統對于用戶而言肯定有一個唯一標識（比如主鍵值、用戶名、顯示名等等），對于消息系統而言，我只要知道這個標識就行了，好賣 馮小剛談中式大片。至于這個標識所代表的是哪個用戶，并不需要關心。把發送人（標識）或接收人（標識）設計成值對象，還有一個重要原因是，如果把發送人（標識）或接收人（標識）設計成實體，那他們可以獨立于消息實體存在，但是我們所設計的是消息系統，并不是用戶消息系統，用戶來自于外部，如果在消息系統中單獨存在就有點不倫不類了，還有就是如果用戶設計成實體，這些用戶實體對象是需要存儲的，這就違背了我們的業務需求。BBC生命Life生命脈動紀錄片下載地址如果把用戶設計成值對象呢？就符合我們現在的消息業務場景了，因為在消息系統中，我們只需要知道用戶是什么，而且用戶獨立于消息，對于消息系統而言將沒有任何意義。