本文章是由機器翻譯。
最佳作法
到網域-導向設計的簡介
David Laribee
本文將告訴您：
|
本文將使用下列技術： Visual Studio |
內容
Platonic 的模型
討論在 Talk
內容
知道您值效益
單一的責任的系統
實體擁有的識別碼，並在存留
值的物件描述的事項
彙總的根目錄組合的實體
網域服務模型的主要作業
存放庫儲存並分配彙總的根目錄
資料庫的重點
月使用者入門
網域導向設計 (月) 會是原則和模式的說明開發人員建立典雅式物件系統的集合。正確地套用它可能會導致呼叫網域模型的軟體抽象概念。這些模式封裝的關閉間距商務實際上和程式碼的複雜的商務邏輯。
在本文中，我將介紹 germane 以月的設計模式與基本概念。這篇文章視為溫和的設計和發展豐富的網域模型簡介。若要要討論的某些內容我使用複雜的商務領域，，我很熟悉： 保險原則管理。
如果意見中介紹訴求給您，強烈建議您加深您的工具箱藉由讀取活頁簿 Domain-Driven Design: Tackling Complexity in the Heart of Software，由 Eric Evans。以上只是原始簡介月，它是一個寶藏 trove 資訊由其中一個業界的最剛接觸的軟體設計。模式和核心要件，月，我將在本文中討論的被衍生自這個活頁簿中所詳述的概念中。
剪下內容，由架構的需求
bounded 的內容 needn't 僅根據應用程式的功能區域組織。它們在分割系統以達成所需的架構範例非常有用。這個方法的典型範例中會是有強大的交易式足跡和報告的公事包的應用程式。
通常很理想，在這種情況下 (這可能很常發生) 報告資料庫從交易式資料庫時中斷。您要以追緝右邊的正規化程度，開發可靠的報告的自由]，而您想要使用的物件關聯對應工具，以便您可以讓程式碼中的物件導向的開發架構的交易的商務邏輯。您使用例如 Microsoft Message Queue (MSMQ) 技術，來發佈來自模型的資料更新並將它們加入至資料倉儲的最佳化的報告和分析之用。
這可能是來某些，為一個驚訝但資料庫管理員和開發人員以及所取得的。bounded 的內容可讓您預覽之後這個 promised 土地。如果您有興趣架構繫結內容，強烈建議讓索引標籤上Greg 將軍的部落格. 他是很有經驗，與明確表達出有關此方法，並會產生一個相當數量內容主體。
Platonic 的模型
由於我們只要這裡關閉開始，它合理實際意思模型所定義的。回答這個問題會導致我們簡短、 metaphysical 的旅程上。比 Plato 的人，引導我們嗎？
Plato，Socrates 的最著名的學生提議的概念、 人員、 地方和動作我們 Intuit 和察覺的我們 senses 是只在真實的陰影。他 dubbed true 的東西這個概念的表單。
為了說明表單，Plato 會使用什麼的會稱為 「 allegory 洞穴的)。這個 allegory，有一個繫結在深層]、 [深的洞穴的人。這些人會鏈結的它們只可以看見，接收開啟的燈號的洞穴的空白牆的洞穴。時所開啟，引導的動物，陰影會投射到內部的牆洞穴) dwellers 看到。洞穴的 dwellers，這些陰影是真正的東西。當一個獅會藉由引導時，它們會指向在獅的陰影，並 exclaim 「 執行的封面 ！ 」 但其實只有真正的表單，獅本身的陰影。
您可以與 Plato 的理論上，表單的月至相關聯。大部分的指引能協助我們更接近理想的模型，一段時間)。表單要描述您的程式碼路徑是有關分散在網域專業處理員的心智、 的利害關係者]，渴望和產業，我們正在處理的需求。這些是，很實際的了解到 Plato 的虛數洞穴 dwellers，陰影。
此外，您通常會受到程式設計語言，並考量的時間和預算，在嘗試連接該表單。這不是的大部分的延伸，說這些限制是洞穴 dwellers 只能夠看到的陰影內部牆的對等用法。
良好的模型會出現數個獨立的實作的屬性。模型的每個人的標頭的相符，問題的事實上是也是您正在認可至程式碼模型，首先應該要瞭解 「 製造模型者 」 的 aspiring 網域。
您所建立的軟體不是在為 true 的模型。它是只顯示 — 如果您將陰影 — 您將從設定為達到應用程式表單。雖然很完美的解決方案的 imitation，您可以設法將一段時間更接近程式碼為 true 的表單。
在 [月，這個概念就會呼叫模型為導向的設計。您瞭解模型是在程式碼中演進。網域為導向的設計工具會而不難 reams 文件或粗圖表化工具的使用。這些搜尋，而，以 imbue 他們感網域的瞭解，直接將他們的程式碼。
擷取模型的程式碼的概念都是以月的核心。藉由保持軟體著重在手邊的問題，並限制為解決這個問題的您會得到新的了解，時間的 enlightenment receptive 的軟體。我喜歡哪些 Eric Evans 呼叫它： crunching 知識庫 」 到模型。當您學習到網域的相關重要的東西時，您會知道權限從何處。
討論在 Talk
讓我們檢查的一些技巧月提供達成此目標。您的工作，身為開發人員的一大部分使用非 coders 瞭解哪些您要傳遞。如果您使用任何類型的處理序與組織中，您可能有需求，為使用者說故事，工作，或是使用大小寫。任何一種需求或您收到的規格會是它通常是完成？
通常需求是瞭解的有點 murky 或表達在高層次而定。在設計和實作解決方案的過程中很有幫助當開發人員將預定的網域部分的專業知識的使用者存取時。這是完全根據到像這樣範本是通常表示的使用者新聞的點： 為 [角色]，我想要 [功能] 所以 [優點]。
從網域的保險原則管理看看其中一個範例： 為的 underwriter，我要核准控制原則讓我可以撰寫安全的曝光度，並拒絕風險的。
有沒有人知道哪些表示嗎？我知道我沒有當我看到寫入並排列優先權。如何可以您可能是瞭解到從這個抽象的描述傳送支援的軟體需要的所有項目？
使用者的故事，正確地完成，是其作者與其交談的邀請，使用者。當您跳至在核准 / 拒絕的原則功能上運作這表示您應該在理想狀況下可以存取的 underwriter。underwriters，的入門的是網域的專家 (至少要有好的是) 使用者會判斷曝光度的特定類別是否安全，涵蓋在電話公司的。
當您開始討論 「 功能與您 underwriter (或您的專案網域專家可能是人，) 付費，尤其是關閉注意到，underwriter 使用之術語。這些網域的專家，使用公司或業界標準的術語。在 [月，這個詞彙呼叫無所不在的語言。為開發人員，要瞭解這個詞彙和與專家的網域時不只是使用它但也會看到相同的術語反映在您的程式碼。如果經常在交談中使用程式條款 」 類別碼 」 或 「 速率設定 」 或 「 曝光度，我會預期要在程式碼中尋找對應的類別名稱。
這是一種很基本的模式，以月。在第一次 blush 普遍的語言似乎的明顯的動作，機會好您的數目已經練習這直接。不過，很重要開發人員使用商務語言程式碼中地和專業領域的規則。這樣可減少商務詞彙和技術 jargon 之間，中斷連線。如何成為附屬於內容，並在您保持接近您的工作的原因： 提供商務價值。
內容
開發人員很，在一個種意義召集人。您可以為抽象，解決問題 sling (希望使用目的) 程式碼。為設計模式、 分層的架構和物件導向原則等工具提供架構將順序套用到 [evermore 複雜的系統。
月會擴充您組織的工具箱]，並從已知的產業模式採用。我喜歡需組織的模式的月所配置的大部分是有每個層級的詳細資料的解決方案在系統中。bounded 的內容會引導您向軟體的想法，為模型的公事包。模組可協助您成較小的區塊中組織較大的單一模型。稍後，我也將說明彙總的根目錄為組織小一些高度相關的類別之間的協同作業的技術。
在大多數的企業系統中，有粗略責任區域。月呼叫此上層組織繫結內容。
工作者 ' 補償保險原則需要考慮使用項目，例如：
- quoting 和銷售量
- 一般的原則 (「 更新 」、 「 終止 」) 的工作流程
- 稽核薪資估計
- 每季 self-estimates
- 設定和管理率
- 發行 commissions 機構和仲介
- 付費的客戶
- 一般帳戶管理
- 判斷可接受的曝光度 (承保)
哇。大量的東西 ！無法將所有的納入單一的整合型系統，但這麼做因此導致您 foggy amorphous 路徑下。人指大約兩個完全不同的項目，當它們交談有關原則，以與原則的薪資稽核內容中一般工作流程的內容中。如果您使用相同的原則類別時，您正在 fattening 該類別的設定檔，並從嘗試-和-true 最佳例如單一的責任原則 (SRP) 中取得長度的方式。
到的架構的樣式 (amusingly) 呼叫的泥大彈珠，名單無法隔離，並通常隔音繫結內容的系統。相同名稱的其傳統紙張中在 1999 年，Brian 地面和 Joseph Yoder 定義的架構上的樣式 (或 anti-architectural 樣式，為情況可能是) (」大的泥的彈珠").
月將微調您向識別內容中，並限制特定的內容中您模型化工作。您可以使用簡單圖表呼叫內容對應，瀏覽我們的系統的界限。我已列舉參與一個功能完整的保險原則管理系統的內容並 [圖 1 帶這從文字描述進入 (部分) 的圖形內容的對應。
[圖 1 從封閉的內容至內容對應
您是否注意到不同的繫結內容之間一些金鑰的關係？這是有價值的智慧的因為您可以開始進行資訊充分的商務和架構決策，例如封裝和部署的設計，； 選擇的技術，可用來封送處理模型，和可能的大部分之間的訊息重要，您選擇設定里程碑，和部署工作]、 [時間和 [人才。
其中一個最後但非常重要的思考有關繫結內容： 每個內容擁有它自己普遍的語言。很重要，以區分核心工作流程中的原則與稽核子系統中原則的概念，因為它們是不同的項目。雖然它們可能會有相同識別碼，之值的物件和子項目 (有更詳細的點) 是通常完全不同。因為您在內容模型的您還需要語言提供的內容中精確度，因此您可以使用網域專家與在您的小組生產力的通訊。
更接近一起比其他的模型群組內的某些區域。模組是的組織作為 Mini-界限，您要停止，並考慮到其他模組關聯這些群組在一個特定的內容中。它們也是會引導您離開 「 泥的小球 」 的另一個組織技巧。 technologically，模組，可輕鬆建立，Microsoft.NET Framework 中直接命名空間。但是，識別模組的圖案包括花一點時間您的程式碼。最後可能會看到出現為一個 mini-model，此時您可能會考慮到命名空間將項目模型內的一些項目。
為凝聚力的模組 teasing 相隔的模型，會在您的 IDE 有一個不錯的效果。也就是，因為您需要使用多個您可以使用陳述式來明確地加入模組，您獲得多清潔器的 IntelliSense 經驗。它們也提供一種方式查看您的系統使用靜態分析工具，例如 NDepend 大概念區塊之間的關聯。
到您的模型中引入的組織的變更應該提示您加入一些 pragmatic、 成本效益的想法。當您使用的模組 (或命名空間)，將您的模型上時，您真的想要問題您是否正在處理不同的內容。通常會更高的另一個內容出 cleaving 成本，是： 現在您有兩種模型，可能在您需要連接控制器，應用程式服務，等等的兩個組件中。
anti-Corruption 的圖層
anti-corruption 層 」 (ACL) 將是您，建議您避免非網域的概念至您的模型中遺漏的工作中建立閘道管理員的另一個月模式。它們保留初始狀態模型。
在他們的心存放庫會是 ACL 的實際上類型。它們保留 SQL，或物件關聯對應 (ORM) 建構之外，您的模型]。
ACL 會是一個很棒技術簡介 Michael Feathers 呼叫，他錄 Working Effectively With Legacy Code，在縫。在縫會是您可以啟動 cleave 關閉某些舊版的程式碼開始介紹 changes.finding 縫，連同隔離您的核心網域，可以時使用重整月技術，則會是非常重要並加強您的程式碼最高值部分區域。
知道您值效益
大部分的開發商店會有少數幾個剛接觸的 businesspeople 和最人員能夠隔離，描述的問題和建置的簡潔、 可維護的物件導向解決方案。最大的就取得您的客戶 buck，要以確定瞭解您的應用程式的核心網域。核心網域會是繫結的內容，讓套用月的大多數的值。
在任何指定的企業系統中，有比其他重要的某些部分。更重要的方面通常屬於與核心) 能力的用戶端的對齊方式。很罕見商務將會執行自訂的一般 Ledger 軟體。但如果該企業在保險 (將我先前的範例中提供) 和提供管理風險的集區的責任會所有成員之間分配其金錢-製作，然後它們有更好是真的很好，在拒絕不正確的風險和識別趨勢。或可能是，您有用戶端的較的醫療宣告處理器，而其策略是 flank 上自動化付款 amplify，努力，其 [帳單收件者 payor 工作團隊的價格其競爭。
任何產業、 您的公司或用戶端會有一些邊緣的市場，此邊緣通常是您找到自訂的軟體。該自訂的軟體是，您可能來尋找和模型的核心網域中。
我們可以我們的投資在到達技術的卓越我們智慧資本也就是測量我們投資上另一個維度中，值。太多次資深開發人員，是人的取得 obsessed 與新技術的類型。特定數量的此為預期 — 業界 innovates 殘酷速度，和廠商會迫使經常發行新的技術解決方案，滿足客戶的需求，並保持競爭力。所面臨的挑戰我看到它，是系統的資深開發人員主要模式，提供值與基礎的原則。很容易就能取得包裝在新的 Framework 或平台中,，但我們需要記住這些事情是，因此我們就可以信任它們的運作，因此廠商產生。
單一的責任的系統
我提到的月提供模式語言的建構豐富網域模型。藉由實作這些模式，您取得特定層級的遵守 SRP 的可用]，並當然重要的。
SRP，鼓勵取得的介面或類別的核心目的。引導您到高 cohesion — 會以個非常好方法使得程式碼探索、 重複使用，和容易維護。
月將識別您，特定的型別的類別的責任，核心模式的集合中。我會討論一些多主要的現在，但值得一提有許多 Eric Evans，原始錄範圍從類別層級到架構中所描述的模式。簡介供我會待在類別層級，其中涵蓋實體、 值的物件、 彙總的根目錄、 網域服務和存放庫。因為這是簡介，我就會只涵蓋使用一到兩程式碼範例或提示每個每個模式的責任。
實體擁有的識別碼，並在存留
實體都是一個 「 東西 」 您的系統中。通常很有用考慮這些方面的名詞： 人位置，和也，動作。
實體會有識別碼和資料生命週期。例如，如果我要在 [我的系統] 中存取特定的客戶，我可以要求為她以一個數字。完成以交易的順序時它會再到 [我的系統死了，並可以前往的長期儲存區 (歷程記錄報告的系統)。
想實體的行為單位而不是資料的單位。嘗試擁有這些實體中放入您的邏輯。大多數的時間有的實體，應該會收到您正嘗試將加入至您的模型的某些作業或全新的 Entity 供建立，或解壓縮。在多個 anemic 的程式碼中您會發現許多的服務或管理員的類別，驗證從外部實體。一般來說，我更想要做的實體中 — 您取得與封裝 (Encapsulation) 的基本原則相關聯的所有優點，並您要讓您的實體 (Entity) 行為。
有些開發人員會打擾的相依性在他們的實體。顯然您需要建立您的系統中不同實體之間的關聯。例如，您可能需要從原則實體取得產品的實體，所以您可以判斷在原則上合理的預設值。當您需要某些外部服務，以執行內建的實體的行為時，人似乎落下會。
我，個，不會干擾牽涉到其他的非實體的類別需要的然後我會嘗試避免提升中央行為以外的我的項目]。您永遠都應該請記住實體都是本質上行為單位。通常的行為都會實作為一種狀態機器的-當您叫用命令的實體上，它負責變更其內部狀態 — 但有時候很需要取得其他的資料，或加上在外部世界的副作用。完成這我慣用的技巧，是提供命令方法相依性：
public class Policy {
public void Renew(IAuditNotifier notifier) {
// do a bunch of internal state-related things,
// some validation, etc.
...
// now notify the audit system that there's
// a new policy period that needs auditing
notifier.ScheduleAuditFor(this);
}
}
這個方法的好處是，您不需要的控制項 (IOC) 容器]，為您建立的實體的反向。 另一種完全在可接受的方法，我認為，是要用來解析在 IAuditNotifier 方法內的定位程式服務。 這項技術有其優點保持介面初始狀態，但我發現前者策略告訴我多瞭解我的相依性有許多在較高層級]。
值的物件描述的事項
值物件會是描述元或在您的模型的網域中重要的屬性。 與實體，不同它們沒有識別碼，； 它們只是描述項目沒有身分識別]。 您是否變更稱為"三十 5 美元"的實體，或會遞增的帳戶的餘額？
值物件的部分是優點的在描述實體的屬性，以更精緻和目的的顯示方式的。 money，Common 值物件看起來更許多好為資金傳輸 API 的函式參數比小數點。 當您在介面或實體方法中找出它時，您會知道哪些您正在處理立即。
值物件是不變的。 一旦建立了它們，它們是無法變更。 為什麼它很重要的它們是不變的？ 與值的物件，您要搜尋的副作用的可用的函式，但另一個概念借用的月。 當您新增 $20 到 $20 時，您會變更 $20 嗎？ 否，您會建立新的金錢描述元的 $40。 在 C# 中您可以使用唯讀關鍵字公用欄位上強制執行的不變性] 和 [副作用的可用的函式，如 [圖 2 ] 所示。
[圖 2 使用唯讀，以強制的不變性
public class Money {
public readonly Currency Currency;
public readonly decimal Amount;
public Money(decimal amount, Currency currency) {
Amount = amount;
Currency = currency;
}
public Money AddFunds(Money fundsToAdd) {
// because the money we're adding might
// be in a different currency, we'll service
// locate a money exchange Domain Service.
var exchange = ServiceLocator.Find<IMoneyExchange>();
var normalizedMoney = exchange.CurrentValueFor(fundsToAdd, this.Currency);
var newAmount = this.Amount + normalizedMoney.Amount;
return new Money(newAmount, this.Currency);
}
}
public enum Currency {
USD,
GBP,
EUR,
JPY
}
彙總的根目錄組合的實體
彙總的根目錄會是實體的一組特殊的消費者直接參考。 識別彙總的根目錄可讓您避免 over-coupling 組成您的模型，藉由較一些簡單的規則之物件中。 您應該注意彙總的根目錄 zealously 保護其 Sub-entities。
請記住最大的規則是實體的唯一的您的軟體可能會保留參考類型彙總的根目錄。 這有助於避免大泥的彈珠，因為您現在有條件約束，防止您建立緊密結合的系統其中所有項目都有與所有其他的關聯。
假設我有一個稱為原則的實體。 也，原則取得更新上的年度的詞彙中，所以可能的實體的呼叫期間。 因為一段無法存在不原則，而且您可以處理期間，透過原則會原則即稱為的彙總的根目錄，而且期間會是相同的子系。
我想我彙總的根目錄到只圖出它。 請考慮一個原則彙總的根目錄的存取這個消費者程式碼：
Policy.CurrentPeriod().Renew()
我試著更新的保險原則 — 回收核心網域的保險原則管理的類別圖表。 請注意我 dotting 我，我要叫用 (Invoke) 的行為方式的方式嗎？
有使用這種方法的問題幾個。 先，我很清楚地違反 Demeter 的法律規定。 在方法 M，物件 O 的應該叫用的只有下列類型的物件的方法： 本身、 其參數、 任何物件，它會建立或執行個體化或其直接的元件物件。
不是 dotting 深層的方便嗎？ IntelliSense 會是最好，最有用的 Visual Studio 和其他現代化的 IDE 功能之一，但啟動 dotting 您實際上您要叫用 (Invoke) 函式的方法時您正在介紹不必要的連接到系統中。 在上述範例中，我現在相依於原則) 類別和期間類別。
延伸閱讀 Brad Appleton 有可用的好文章說明更深層的含意理論，tooling，解決警告他網站上， Demeter 的法律規定.
cliche 的 「 死亡的千位捷徑 」 將是您，好的潛在的維護夢魘過結合系統的描述。 當您建立不必要的參考，各地將時，您也會建立嚴格的模型，其中變更在一個地方會導致在重疊的各地消費者程式碼的變更。 您無法完成相同的目標，遠，我是關於，更具表達力一點程式碼：
Policy.Renew()
請參閱如何彙總就判斷它出？ 在內部，它也可以找到目前期間，已經有的更新句號和任何其他您需要它執行。
我發現我在我的測試趨勢向更 「 黑箱 」 和 「 測試狀態的開發架構的單元測試使用技術如行為的驅動程式開發 (BDD)，我彙總的根目錄時。 彙總的根目錄和實體通常最後狀態的電腦為和行為符合適當。 我得到狀態驗證、 加入和減法。 有有點相當的行為進行在更新範例中，在 [圖 3 ，和它很清楚您如何可以表達此測試的 BDD 樣式中。
[圖 3 測試彙總根
public class
When_renewing_an_active_policy_that_needs_renewal {
Policy ThePolicy;
DateTime OriginalEndingOn;
[SetUp]
public void Context() {
ThePolicy = new Policy(new DateTime(1/1/2009));
var somePayroll = new CompanyPayroll();
ThePolicy.Covers(somePayroll);
ThePolicy.Write();
OriginalEndingOn = ThePolicy.EndingOn;
}
[Test]
public void Should_create_a_new_period() {
ThePolicy.EndingOn.ShouldEqual(OriginalEndingOn.AddYears(1));
}
}
網域服務模型的主要作業
有時候，您必須作業或未在您的網域中安裝的識別碼] 或 [存留週期的處理程序。 會網域服務給您一個工具模型這些概念。 它們通常是無狀態] 和 [高度凝聚力，通常提供單一的公用方法和有時是多載上設定的動作。
我要使用一些原因的服務。 當有許多的相依性所涉及的問題，並無法找到自然的位置，將該行為的實體上時，我使用服務。 當處理序或作業順序的第一個概念的相關我 [普遍的語言] 討論我將問題是否服務可以為協調資料中心點的流程模型的。
您無法使用網域服務在更新的情況下。 這是一個替代的樣式。 而不是插入的 IAuditNotifier 直接到原則實體 (Entity) 的方法之方法的更新方法，您可以選擇解壓縮為我們處理相依性解析網域服務，更自然的解析網域服務 (從非實體的 IOC 容器。 這項策略合理更多我有多個的相依性，但我仍會顯示替代方案。
以下是網域服務的簡短範例：
public class PolicyRenewalProcesor {
private readonly IAuditNotifier _notifier;
public PolicyRenewalProcessor(IAuditNotifier notifier) {
_notifier = notifier;
}
public void Renew(Policy policy) {
policy.Renew();
_notifier.ScheduleAuditFor(policy);
}
}
[文字服務會是一個高的多載的術語，在開發人員世界中。有時候我認為的服務為在服務導向架構 (SOA) 中。其他時候，我想到的服務，為一些類別，不代表特定使用者、 位置或在我的應用程式，但 embody 處理程序，通常。網域服務通常會落在這個後者的類別中。它們通常命名為動詞命令或網域的專家引入普遍的語言的商業活動之後。
應用程式服務，從另一方面來說，會是介紹分層的架構一個好方法。它們可用於用戶端應用程式所需圖案對應網域模型內的資料。例如，您可能需要資料的 DataGrid 中的顯示表格式資料，但您要保留在細微和不規則中的物件 Graph 您的模型。
應用程式服務也很整合多個模型很有用 — 例如，轉譯之間原則稽核和核心原則工作流程。同樣地，我使用它們將基礎結構的相依性加入至混合。假設您想要公開您的網域模型，與 Windows Communication Foundation (WCF) 常見的案例。我想使用應用程式服務的裝飾與 WCF 屬性這發生而不是到我的純網域模型讓 WCF 遺漏 (Memory Leak)。
應用程式服務通常非常廣泛，並表層，embodying 凝聚力的功能。請考慮介面及部分的實作您看到 [圖 4 ] 中，程式碼中使用的應用程式服務的例子。
[圖 4 A 簡單的應用程式服務
public IPolicyService {
void Renew(PolicyRenewalDTO renewal);
void Terminate(PolicyTerminationDTO termination);
void Write(QuoteDTO quote);
}
public PolicyService : Service {
private readonly ILogger _logger;
public PolicyService(ILogger logger, IPolicyRepository policies) {
_logger = logger;
_policies = policies;
}
public void Renew(PolicyRenewalDTO renewal) {
var policy = _policies.Find(renewal.PolicyID);
policy.Renew();
var logMessage = string.Format(
"Policy {0} was successfully renewed by {1}.",
Policy.Number, renewal.RequestedBy);
_logger.Log(logMessage);
}
}
存放庫儲存並分配彙總的根目錄
您哪裡，擷取實體？您是否方式儲存它們？這些問題的回應儲存機制的模式。存放庫表示的記憶體中的集合中，傳統的智慧您會得到一個每彙總的根目錄的儲存機制。
儲存機制是超級類別或 Martin Fowler 層的超級類型模式指向很適用的。使用泛型衍生一個基底的儲存機制介面從先前的範例是簡單：
public interface IRepository<T>
where T : IEntity
{
Find<T>(int id);
Find<T>(Query<T> query);
Save(T entity);
Delete(T entity);
}
儲存機制會防止資料庫或持續性的概念，例如 SQL 陳述式或預存的程序，commingling 與您的模型和 distracting 您的手邊的任務： 擷取網域。此模型的程式碼分開從基礎結構會是不錯的屬性。請參閱資訊看板 「 anti-corruption 層 「 如需更詳細的討論。
這時候您會注意可能到我不談如何彙總根目錄其從屬的實體，並附加的值物件實際上取得保存至磁碟。這是故意的。儲存在您的模型中執行行為所需的資料是正交模型本身的考量。持續性，是基礎結構。
這些技術的調查遠超出簡介月的範圍。就說 suffice 有很多適合] 和 [成熟的選項，用來儲存您的模型資料從物件關聯對應 (ORM) 架構文件導向的資料庫以簡單的案例的彙總 」 套件您-擁有 「 資料 mappers。
月資源
資料庫的重點
這點，我確定您所認為 「 這是都沒問題，Dave。但其中儲存我的項目嗎？ 」 是，您有以處理這個重要的詳細資料但如何或，您會保存您的模型主要 tangential 月之概觀。
許多開發人員或資料庫系統管理員 」 會讓資料庫會是模型的判斷提示。在案例許多的部分為 true。資料庫，高度正規化和視覺化的使用在圖表的工具時可以傳遞許多有關的資訊和關聯性，在您的網域中。
資料模型做為主要的技巧會使有需要，但是。當您要瞭解相同的網域資料-只技術 (例如實體的關聯性圖表 (ERDs) 」 或 「 實體的關聯性模型中固有的行為並在類別圖表的細分。您要查看在影片和型別共同作業，以取得如何完成的應用程式的部份。
當我模型時，我通常達到白板上的順序圖表作為通訊工具。這個方法會擷取大部分的通訊是行為的設計 」 或 「 而 Unified Modeling Language (UML) 的模型為導向的架構，典禮的問題的本質。我要我要清除，我將在白板的圖表時，特別是，請避免不必要的儀式。我擔心大約 100%在我的圖表，偏好簡單的方塊 」、 「 箭頭和 「 swim 巷道，我可以快速草擬的 UML 遵守。
如果您已不使用順序圖表，在您的小組，我會高度建議學習技術。我所觀察到的功能強大的效果，它們對周圍 SRP，分層的架構資料行為的設計，想的小組成員取得透過問題模型，和架構想一般來說。
月使用者入門
成為 proficient 與物件-導向程式設計，是沒有一般的任務。我相信 competence 是內，reach 最專業開發人員，但它會採用 dedication，錄學習，實務，實務和更多的作法。它也可以協助如果您採用 craftsmanship 的持續學習的態度。
您如何開始？簡單地說： 執行您的作業。深入了解像是，S.O.L.I.D.原則並研究 Eric Evans ' 活頁簿。您的時間投資多個將本身的組成。InfoQ 產生月本書，介紹幾個主要概念的較小版本。如果您是在財務或暫時的預算或只是調查模式，我會建議有啟動。一旦您取得穩固的濕，wander 透過以Yahoo!月群組若要查看您的夥伴，設計工具 struggling 與和取得參與交談的問題。
月不是新的教義或方法。這是 time-tested 策略的集合。取得要練習時，請嘗試調整這些原理 」、 「 技術和 「 在您的情況下，使最有意義的模式。月的某些項目比其他更普遍的套用。瞭解核心網域的存在原因 uncovering 並使用非常普遍的語言識別，我們在模型的內容很方法更重要，比 nailing，完全不透明和 one-size-fits-all 的儲存機制的。
當您在設計解決方案時, 設計值。如果設計工具產生的圖案，並且開發人員一種類型的設計工具，然後我們中必須是商業價值。值 consciousness trumps 的考量，例如 dogma，並為重要，有時候看起來這些選擇的保存性技術的選擇。
Dave Laribee coaches 的產品開發小組在 VersionOne。他經常在本機和國家的開發人員事件演說，並已將在 Microsoft 架構 MVP 授予 2007 的 2008。他也撰寫在 CodeBetter 部落格網路thebeelog.com.