本文章是由機器翻譯。

編輯備註

架構和彙總

Howard Dierking

從文件內容，您可以看到 我們在這個月著重軟體架構的相關問題。 而且我想善加利用這個編輯器的討論內容我已經花費一些時間思考最近附註以及這些行，— 彙總。

現在的人有樂，以符合所取得的 (或其我相關的) 可以 attest 到至少兩個優點。 先，我永遠興奮，討論軟體開發 — 在特定的架構。 第二，在這類的對話內容我傾向於交談 louder 和我的動機成長的速度 (這 amplified 像我的好朋友 Glenn 區塊的其他人加入混合)。 彙總會是我興奮真的有關，請確定已開啟關閉您的喇叭這些架構的主題之一。

彙總會是使用大量 practitioners 導向設計 (月) 的網域的名詞，並定義為 「 關聯的物件，會被視為單位的資料變更的目的的叢集。 外部參考的彙總指定為根目錄的其中一個成員的限制大小寫。 一組一致性規則套用彙總 (Aggregate) 功能的界限內 」。

現在請讓我說我不是只 believer 腐爛和考慮資料的模型的這種方式，但我進一步認為無法建立強式的彙總界限是其中一個主要背後，hopelessly 結合到關聯式資料庫結構描述，並太糾結來輕易地發展來支援以訊息為基礎的開發架構，因為這些使用定域機組電腦架構 spaghetti-類似的應用程式設計的驅動程式。

不過，在某些的情況下我想我們可能會有關差方式定義彙總的界限的程序。 我在問題的根目錄的考慮不論是否您先設計資料庫或物件模型首先，兩個表示產生的精密的邏輯實體結構)，並思考抽象的這種方式導致我們忽略了簡化的機會。

若要將這放入範例，我已工作開發 Microsoft Word 增益集，將 manuscript 文件中的繼資料的繫結。 在 SharePoint 管理中繼資料 — 其，資料庫的詞彙感覺更像 Kimball-樣式的資料倉儲的星狀拓樸。

我開始設計應用程式建立網域模型。 初始案例，我希望支援已瀏覽文件的清單，及選取 「 應該與相關聯，manuscript。 因為我想不擊敗我巨人的文件清單的使用者，我加入巡覽案例使用自然階層架構，Magazine 包含其中包含文件的問題。 相識嗎？

因此有什麼問題？ 這個模型類似我們所有看到無數的時間上的模型。 不過，也是這種模型的人員遇到定義彙總的界限的問題。 為什麼？ 因為它以基礎結構，而不是問題。 為了重述我的案例，我想要讓我的使用者巡覽的一組使用自然階層架構的文件。 由該的邏輯我階層會是只要投影文件的集合)，此變更我的模型，如上述所示，我有一個清楚定義的單一文件，彙總。

現在，這是不假設您應該永遠不會在您的物件模型中有傳統的階層架構。 而，我試著說的而不嘗試如果要在資料的模型中繪製周圍一組類別的資料行定義彙總先定義根據行為，粗略彙總，然後讓您的類別會出現在彙總的定義。 您將會避免嘗試取得彙總的定義對 」 的 [分析 paralysis，並且您將會開始出在右邊的地面上建置您的系統根據行為對結構]。

請造訪我們在 msdn.microsoft.com/Magazine. 疑問、 意見或 MSDN Magazine 建議嗎？ 傳送到編輯器： mmeditor@Microsoft.com.

感謝到文章提供，Microsoft 技術支援專家： 協助解決問題 Jean-Paul Boodhoo、 Pablo Castro、 Ben Constable、 Jeff Derstadt、 Chuck Esterbrook、 Eric Fabricant、 Steve Freeman、 Ashok Kamath、 Bertrand LeRoy、 nat Pryce、 Ashish Shetty，Don Smith、 Chris Tavares、 Kevin Hoffman、 Dave Fugate、 Harry Pierson、 Curt Hagenlocher、 Lynn Langit、 Varsha Mahadevan、 Stephen Toub、 標記 Lawrence 和 Henri Socha。