這裏我們再次處於十字路口。MVC + WCF + TDD或DDD架構
我想嘗試實施，至少在未來3年內，構建我的應用程序的一種簡單，經過驗證的方法。 每次我要開始一個項目時，都覺得這是第一次，因爲最近有很多「途徑」來創建網站。
我有這個示例代碼，我從這個包購買調用設計模式框架4 C＃。在他們擁有的多個項目中，有一個叫做Design Patterns in Action。你可以從這裏下載https://skydrive.live.com/redir?resid=B853B0DB724C30E5!16735&authkey=!AOeHSAWa_P4vzzU
我的問題是，當你看一下這個解決方案後，你會保留什麼，你會保留什麼，什麼是不必要的，等等等等。
據我所知，他們試圖展示多個客戶端和多個DAO。但總的來說，這個架構是否會成爲一個「模板」？ 謝謝。
我的問題，你該解決方案看一看之後，什麼是好的，壞的， 關於這個例子，你會保留什麼，你會刪除什麼，什麼是不必要的等 ？
快速瀏覽後，這裏就是我想要說的話：
至於你的問題的DDD標籤，這顯然不是一個域驅動架構。除了一些簡單的驗證規則外，業務對象還有anemic，並且DDD體系結構的許多基本構建塊不存在（聚合，值對象等）。
除非我錯過了某些東西，否則大多數業務操作是CRUD操作，它並不真正代表真實世界的企業應用程序。
有一個胖胖的服務層，它有一個基本上可以處理應用程序所有用例的胖ActionService類。好消息是，它以不可知論的方式處理用例（據我所知，它操縱的Request和Response對象是獨立於交付機制的）。因爲這個職業包含了太多的責任（SRP），所以發胖是不太需要的。
在客戶端使用存儲庫和服務器端的DAO似乎很奇怪，但爲什麼不。
如果它真的是測試驅動的，爲什麼不包括所有的單元測試而不是僅僅一個樣本呢？
除此之外，這些層被精心設計和作爲多個呈現層顯示，它不應該是困難替代一個前端爲另一個或另一個持久存儲中。
感謝您的回答。這不是一個「完整的應用程序。我認爲他們很想展示不同的模式如何協同工作等等。在閱讀了關於DDD的一些信息後，我意識到它與DDD無關。 我認爲他們在客戶端擁有倉庫的原因是爲了能夠統一它。這就是文檔所說的。事實上，這個示例還帶有一個Windows窗體示例以及wpf，webforms（mvp）。但我刪除它，因爲它與我的問題無關。事實上，MVC項目是唯一使用存儲庫訪問服務的項目。 –
我想這個示例會更好地使用輕量級的應用程序，不會增長。快點。同意？ –
輕量級不一定是我描述它的方式。您可以感覺到架構設計爲模塊化，並增加了很多抽象層以使模塊化成爲可能。就像我說過的，你可以很容易地將一個外圍層交換爲另一個外圍層，這對於UI基本上直接與數據庫交談的輕量級應用程序來說並非如此。 – guillaume31
系統架構很像建築結構：
有許多因素進入choosi ng體系結構：
所有這些讓我感到驚訝，如果你能想出一個全面的框架來適應你未來3年的每個項目。將MVC，WFC，TDD，DDD等視爲工具，您可以使用它來構建
右邊
系統可以滿足這種情況的需要。
我的意見是：只要符合特定情況，就可以使用任何你能理解的概念（並且可以教他人）。
更好的系統架構，我們可以進去並改變我們的建築：） –
我明白你的觀點。我試圖在Web應用程序中涉及的所有元素之間取得平衡。我想最讓我困惑的是你發現的絕大多數「最佳實踐」。現實是他們多次反駁自己。我正嘗試使用上述解決方案爲自己設置一個「工作模板」，因爲我的所有應用程序的結構都非常相似。感謝您的回答。 –
正如@d_stanley所說，MVC，WCF，TDD和DDD是工具，框架，方法論，最佳實踐的集合等。如果您遵循設計模式中的字母DDD，TDD就會狂熱地摧殘一個項目是一個工具包，你可以從中選擇（你不應該嘗試在每個項目中都使用它）。 MVC和WCF是時髦的框架，可以更容易地分別創建/處理網站和通信，並且是全面的良好選擇。 –
最重要的是確保您使用可重構的模式。如果你使用TDD並且發現你可以注入你的依賴關係，假貨等，那麼這將緩解重構過程。使用任何特定模式的三年時間都很長。有朋友說，如果你不看代碼6個月回來，並認爲它很爛，那麼你可能不會學習不夠：）
你看完六個月大的代碼是完全正確的。這正是我想要做的：不要陷入編碼的「完美主義者」一面。我發現這段代碼看起來非常健壯，也有點通用，但至少它讓你瞭解了許多「正確」操作方法之一。 –
你可能會得到的唯一答案是「我認爲XYZ是好的，因爲我使用它」 –
沒有魔力子彈，一種尺寸適合所有治療。你使用任何能使你工作效率最高的東西。 –