2

當我輸入這個時,我意識到這很難解釋。如果它是不可分辨的,我很抱歉。我的最終目標是讓有更多經驗的人瞭解我如何構建我的解決方案,並提供關於它是否可接受的設置的反饋。如何使用C#.NET實現DDD 4

我目前管理幾個彼此鬆散相關的小型支持項目。他們都是全面的。我想創建一個統一的INTERNAL-WEB應用程序來管理這些項目。我已經設法將一切概念上分成三個域。運輸,外部網絡,內部網。從業務角度來看,SHIPPING將WIDGET發送給客戶,然後客戶連接到EXTERNAL-WEB。問題在於SHIPPING對WIDGET和CUSTOMER的定義與EXTERNAL-WEB定義不同,所以我需要將這兩者分開。

經過一番思考,我得出結論,在VS2010中組織這個最好的方法是創建一個解決方案,然後在解決方案中嵌套多個項目。我在設想如下的佈局。

SOLUTION 
---SOLUTION.SHIPPING.Domain    (Classes) 
---SOLUTION.SHIPPING.Infrastructure  (Classes) 
---SOLUTION.EXTERNAL-WEB.Domain   (Classes) 
---SOLUTION.EXTERNAL-WEB.Infrastructure (Classes) 
---SOLUTION.INTERNAL-WEB.Domain   (Classes) 
---SOLUTION.INTERNAL-WEB.Infrastructure (Classes) 
---SOLUTION.WebUI      (MVC3 Project) 

我必須添加額外的項目範圍內的地圖和反腐敗層在不同域之間的通信,但是這是基本的佈局。

這是聰明還是愚蠢?

感謝, 格雷格

+2

值得注意的是,DDD更多地與您開發與客戶溝通的「無處不在的語言」,而不是實際的編碼。 – 2011-02-17 00:07:17

回答

2

您如何配置你的解決方案無關,與DDD,並不會影響你的項目的成功。 糟糕的組織好的代碼比組織良好的錯誤代碼要好得多。

項目具有與其相關的生產力和複雜性成本。現在你正在爲一些並不重要的細節而煩惱。

更多的項目也等於較慢的編譯時間,這增加了上下文轉換。嘗試閱讀一本書並每頁停留30秒。

應該爲部署或代碼共享目的創建新項目。很好的理由包括,如果域名在兩個前端之間共享,或者如果你有一個怪異的部署策略(1000臺機器),MB仍然很重要。

一旦您簡化了新項目的規則,隨着代碼庫的成熟以及新的需求的出現,決策開始自然而然地展開。你基本上是在最後一刻做出實際決定。這很好。當你有功能和代碼寫入時,不要BUFD!


不確定爲什麼這個問題被標記爲MVC,但MVC代碼庫相當精簡,只有一個主項目。編譯速度快,並且很容易導航。