关于构造域驱动设计命名空间的一些问题

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分钟）。如何回答一些问题有很好的做法。