如何着手創建一個總結

Question

這次我想到的問題是構建一個聚合需要什麼樣的抽象層次。

例如 順序由上OrderWorkflowHistory，評論

難道我去
訂單<> - OrderWorkflowHistory <> - WorkflowActivity
訂單<> - CommentHistory <> - 評
OR
訂單<> - WorkflowActivity
訂單<> - 評論

Where OrderW orkflowHistory只是一個將封裝所有發生的工作流活動的對象。它維護一個列表。訂單只是將維護活動列表的工作委託給此對象。

CommentHistory同樣是用戶附加的（列表）評論的包裝。

當涉及到數據庫時，最終將訂單寫入ORDER表，並將工作流活動列表寫入WORKFLOW_ACTIVITY表。 OrderWorkflowHistory在持久性方面沒有任何重要性。

從DDD的角度來看，這是最理想的。請分享你的經驗！

Answer 1

正如你所描述的那樣，容器（OrderWorkflowHistory,CommentHistory）似乎沒有封裝太多的行爲。在此基礎上，我會投票放棄它們並直接在Order中管理列表。

一個警告。您可能會發現列表中所需行爲的數量不斷增加（例如複雜的搜索）。如果發生這種情況，引入一個/兩個容器來封裝該邏輯並停止變得臃腫可能是有意義的。

我很可能從簡單的解決方案（沒有容器）開始，只有在正確的情況下才引入它們。只要外部客戶通過Order的界面撥打所有電話，您就可以在內部重構Order而不會影響客戶端。

hth。

Answer 2

這是一個很好的問題，如何建模和豐富您的域名。但是很難回答，因爲它對於不同的領域有很大的差異。 我的經驗是，當我開始使用DDD時，我得到了很多存儲庫和一些價值對象。我重讀了一些書，並以開放的心態研究了幾個DDD代碼示例（有很多不同的方法可以實現DDD，但並非所有的都適合您當前的項目場景）。 我開始嘗試記住「更多價值對象，更多價值對象，更多價值對象」。爲什麼？ Well值對象帶來的緊密依賴性更少，行爲更多。 在上面的例子中，有一對多（1-n）的關係，我已經解決了1-n rel。以不同的方式取決於我的使用情況使用域。 （1）有時我創建一個包裝類（就像你的OrderWorkflowHistory），它是一個值對象。子對象的整個列表在創建對象時設置。當您有一組必須在一個請求期間設置的子對象時，此方案很好。例如問卷表上的調整重量。然後所有問題都應通過Questionaire.ApplyTuning（QuestionaireTuning）方法得到問題權重，其中QuestionaireTuning就像您的OrderWorkflowHistory（一個List的包裝器）。這增加了很多域： a）問卷將永遠不會處於無效狀態。一旦我們應用調優，我們會對問卷中的所有問題進行調整。 b）QuestionaireTuning可以提供很好的訪問/搜索方法來檢索特定問題的權重或計算平均體重分數等。

（2）另一種方法是擁有1-n包裝類不是Value對象。如果你想不時添加一個子對象，這種方法更適合。由於x個子對象，父代不能處於無效狀態。這個典型的包裝類有Add（Child ...）方法和幾個search/contains/exists/check方法。

（3）第三種方法是將IList暴露爲只讀集合。您可以使用擴展方法添加一些搜索功能（.NET 3.0中的新功能），但我認爲這是一種設計氣味。更好地通過列表包裝類來封裝提供的列表訪問方法。

對於方法一的一些示例，請看http://dddsamplenet.codeplex.com/。

我相信整個討論與建模值對象，實體和誰負責什麼行爲是最集中在DDD。請分享你的想法圍繞這個話題...