關於構造域驅動設計命名空間的一些問題

Question

我有一些關於框架設計的一般問題。

我正在爲C＃.NET（framework 3.5），& SQL 2008（使用LINQ）構建iPhone應用程序的API。我遵循領域驅動設計模式（在一本書）和 有以下文件夾結構：

Core 
- DataAccess 
--Impl 
-Domain 
-Impl 

Core是我的核心API庫 - 我的DLL。 DataAccess包含數據訪問接口 DataAccess.Impl包含存儲庫（LINQ到DB） Domain包含我的大部分數據類型和屬性。 Impl包含我的服務（即AccountService.cs，EmailService.cs）

現在，作爲練習，我已將Windows服務添加到此項目 ，並試圖從此服務中的DLL調用功能。 我的問題是，我應該暴露給其他應用程序 什麼層應該保持隱藏？

• 應該從程序員看到的Impl文件夾的服務類？
• 還是來自DataAccess.Impl的存儲庫？
• 或者，我應該把所有的東西都放到程序員看到的地方嗎？現在看起來 ，這似乎有點混亂。

當我開始閱讀關於DDD我假定庫將 隱藏的，由服務類訪問，但我發現我需要同時在我的客戶打電話 功能。我設計了這個錯誤嗎？

我的另一個問題與命名空間命名有關。當從我的核心庫中的Windows服務 通話功能，我必須做我的包括這樣：

using Company.Product.ProductCore.Core.DataAccess.Impl 
using Company.Product.ProductCore.Core.Domain 
using Company.Product.ProductCore.Core.Impl 

這似乎羅嗦。看着微軟的DLL，他們似乎保持了兩層的約定 - （System.Linq，System.Text等）。有Company.Product.ProductCore.Core.Impl 似乎混亂，並沒有真正告訴程序員這個命名空間是什麼（但它是 是我讀過的例子建議的）。這裏有最佳做法嗎？

您的建議（以及任何示例）都受到了重視。

謝謝。

Answer 1

這個域名絕對不是你要找的，在我看來，你的數據訪問層也不是。

在我的小見解中，如果我們考慮Façade設計模式（它暴露了您的庫子系統的特性和功能），那麼將不得不暴露的東西還沒有出現，即靜態類。

門面設計模式說明：

1. Façade Design-Pattern - (Gang of Four);
2. Facade pattern (Wikipedia)。

所以最後，你的代碼應該做什麼？只要揭露你應該知道的必要條件，因爲你是唯一知道你正在開發的系統的人。

簡而言之，我經常使用Façade模式，以便我可以在外觀罩下隔離我的類，實現和幾個相關的子系統。讓我們考慮我們是一個全新的汽車經銷商。這個外觀將成爲讓您看到在展廳露出的汽車的絕佳窗戶。你必須考慮這個外觀所暴露的內容。它只暴露汽車嗎？

在我看來，這個外觀暴露了汽車，你可以購買，借錢購買，修理汽車，購買其他相關配件等。然後配件將被暴露，但只有需要什麼。與其他物品如汽車一樣。也就是說，你可能只想公開一個接口，併爲自己保留實現，所以通過你的外觀，當你要返回一個ICar或一個IAccessory，你必須通過你的實現對象類實例化它們，然後返回通過你的façade界面實例。也就是說，用戶不需要知道引擎蓋下面發生了什麼，但是隻有當他想要一輛汽車時，他必須通過你的外觀命令它。就像你不會去買一輛馬自達3到梅賽德斯奔馳一樣。您將使用正確的外觀。再次，不同的汽車經銷商可能只是子系統，因此有些工廠。然後，你問外立面有這個和那個規格的汽車，外牆應該知道什麼ICar實例返回交換你要求它提供給你的東西。

希望這有助於反正！ =）

Answer 2

如果我沒有記錯的話，你問兩個問題：

1. 如何構建一個DDD應用程序？
2. 那些長命名空間名稱呢？

我的回答相當長 - 我冒昧地將它分解爲兩個動物。

這是一個問題的第二個問題：

2.什麼那些長的命名空間名稱

我不認爲長名字空間是必然混亂。 恕我直言，是什麼在你的名字看起來雜亂無章是：單詞「產品」和「核心」

使用的總稱

• 重複「默認地將Impl」

第一個改進可能是：

// The Domain objects go here; 
MyCompany.MyProduct.Core.Domain; 
// DataAccess interfaces go here: 
MyCompany.MyProduct.Core.DataAccess; 
// a Linq implementation of the DataAcces interfaces go here: 
MyCompany.MyProduct.Core.DataAccess.LinqImpl; 
// The Core service go here: 
MyCompany.MyProduct.Core.Services; 
// Some general purpose infrastructure goes here (e.g. emailing code) 
Mycompany.MyProduct.Infra; 

而且，我發現，在代碼結構中使用的商業產品名稱（如myProduct的）是壞的（如果有什麼營銷選擇一個不同的名字？ ）;我喜歡使用邏輯子系統的名稱。 讓我們假設你的建築汽車租賃系統。然後CarRental將被視爲這個應用程序的核心功能。然後我會使用以下命名空間結構（塞拉是我公司的名稱）：

// For classes Customer, Account, Car 
Serra.CarRental.Domain;  
// I use Dao as a general abbreviation for "Data Access Objects" 
// Dao interfaces go here: 
Serra.CarRental.Dao;  
// Linq implementation for Dao interfaces 
Serra.CarRental.Dao.Linq; 
// For Services specific to the car rental domain: 
// AccountService and RentalService and CarAvailabilityService 
Serra.CarRental.Services; 
// For UI objects (not relevant in you situation?) 
Serra.CarRental.UI; 
// general service code; ignorant of the CarRental domain (e.g. an EmailService) 
Serra.Infra.Service;  

Answer 3

我懷疑你的應用程序的用戶將看到這一點。 您需要的第一件事是功能。這是你最後會賣的東西。

此外，您還需要儘可能降低維護費用。這裏介紹了你的代碼是如何組織的。 第二件事 - 儘量減少維護費用。

所以要決定如何安排你的解決方案，你應該回答一些問題：

1. 如何拿起結構將幫助我 做維護和增加新的功能 ？
2. 它將如何幫助開發人員在我的 解決方案中開始編碼的新 ？
3. 是所有那 程序集/文件夾/類的名稱是 可識別和描述？
4. 我忘記了的問題。

這是你的目標。但不是你正在尋找的規則。 如果新的開發人員能理解他們，你可以選擇任何名字。

可能（作爲啓發式，如果您使用Resharper或Refactor！Pro等重構工具），您可以從單一程序集和單個名稱空間開始。在開發過程中，您會看到如何改變項目結構以更好地滿足您的需求。然後重構它。

去看這個talk在38：18-39：45（約1.5分鐘）。如何回答一些問題有很好的做法。