本文章是由機器翻譯。

編輯備註

推動設計

Howard Dierking

在本期 MSDN Magazine，重點我們注意與軟體設計的最佳作法的相關主題。 這個主題會是一個個人的最愛，因為良好的設計的作法是普遍跨所有的 sub-specialties 軟體開發。 我們主題範圍從接受度測試] 和 [IronRuby 到簡報模式在 WPF 中有一個吸引人的內容 — 甚至奧斯陸 」 平台的概觀。

我，最感興趣的 「 但是，是 Dave Laribee ＜ 的 Introduction to 驅動的網域設計 ＞。 我已經一個訂閱者 」 和 「 practitioner 的網域-導向設計 (月) 考慮，因為我讀取 Eric Evans 錄以相同名稱的大約四年前，並有成長的最少的發生問題的思考這種方式。 我相信這已主要是因為以驅動的網域設計、 豐富的網域模型模式和測試驅動開發之間互補的關聯性。

但建置軟體時，沒有任何的銀。 我會監看 Windows Workflow Foundation (WF) 和 Windows Communication Foundation (WCF) 等技術繼續發展，； 我看到持續向服務導向移位。 和我無法在 [說明]，但不知道是否我貫徹遵守某些實務和啟發學習法已經造成我重新建立我自己的一些滾輪，並接著會破壞良好的軟體設計的目標之一，建立更容易維護的系統。

讓我們保險問題網域 Dave 參考其文件中。 我，太，一次此產業中，建置哪些我被視為而典雅式架構驗證原則設定的計算預測稱為圖例。 我建立我的網域模型，從外部使用以測試為導向的方法，對應到資料庫使用受歡迎的物件關聯對應工具的我的模型，並投射到多個介面層級的我的模型。 我持續重整我的網域模型，我注意到兩件事。 先，所有邏輯 (及所有的我必須建置的測試) 都開始類似我也發現之前的項目。 此外，實際上時我逐步執行回看我的網域模型, 我發現我有基本上寫入自己的順向鏈結規則引擎。

讓記住，最容易維護程式碼是不需要維護，請考慮如何計算原則說明的程式碼。 由使用在功能 actuarial 褪通常 symbolic 語言 (例如 APL 或 mathematica 建立公司的實際計算邏輯。 然後此邏輯已轉譯到我們的物件導向的網域模型。 如我相信您可以推算，迴歸測試期間找到一個很棒的許多錯誤引入的這項轉譯。

我懷疑我自己的經驗的看我的應用程式會有起來像我必須重整我的驗證邏輯到一個規則引擎，採取以更 polyglot 方法，來計算。 將我的應用程式仍然已經 「 網域驅動 」 嗎？ 或是可以月原理分隔從其更頻繁的物件導向的實作？

我已檢閱最近，我舊程式碼想要查看的月原則的我的瞭解有被偏移我 OO 編碼技術中，然後重整更適合的開發架構應用程式的適當部分。 哪些我已完成為止是網域驅動想法仍然設計軟體的重要部分。 (在實際上月的特定項目成為 multi-paradigm 的設計中更有意義)。 在的最後我的經驗已驗證的事實上，網域必須磁碟機設計 — 甚至當它挑戰是我們身為項 o 人員習慣。

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

感謝到文章提供，Microsoft 技術支援專家： 協助解決問題 Surupa Biswas、 Mike Calligaro、 John Gossman、 Tim Heuer、 Ed Katibah、 Gaurav Khanna、 Ravi Krishnamurthy，Mike Magruder、 Rick Molloy、 Dave Murray、 Michael Puleio，王俊元 Schmidt、 Don Smith 和 Matt Winkler。