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

Question

我有一些关于框架设计的一般性问题。

我正在 C#.NET（框架 3.5）中为 iPhone 应用程序构建 API，& SQL 2008（使用 LINQ）。我遵循了领域驱动设计模式（在一本书中）并且 有以下文件夹结构：

Core
- DataAccess
--Impl
-Domain
-Impl

Core 是我的核心 API 库 - 我的 DLL。 DataAccess 包含数据访问接口 DataAccess.Impl 包含存储库（LINQ to the DB） 域包含我的大部分数据类型和属性。 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. 外观设计模式-（四人帮）;
2. 外观模式（维基百科）。

那么最后，你的代码应该做什么？只需公开您应该了解的必要内容，因为您是唯一了解您正在开发的系统的人。

简而言之，我经常使用 Façade 模式，这样我就可以将我的类、实现和几个相关的子系统隔离在外观的背后。假设我们是一家全新的汽车经销商。这个立面将是巨大的窗户，让您可以看到陈列室中暴露的汽车。你必须想一想这个外观暴露了什么。它只暴露汽车吗？

在我看来，这个立面暴露了汽车，你可以购买汽车，借钱购买，修理汽车，购买其他相关配件等。配件是要暴露的，但只是需要暴露的。汽车等其他物品也是如此。也就是说，您可能只想公开一个接口，并为自己保留实现，以便通过您的外观，当您必须返回 ICar 或 IAccessory 时，您必须通过实现对象类实例化它们，然后通过外观返回接口实例。也就是说，用户不需要知道引擎盖下发生了什么，但只要他想要一辆车，他就必须通过你的外观订购它。就像你不会去买马自达3去买奔驰一样。您将使用正确的外观。话又说回来，不同的汽车经销商可能只是子系统，因此是某种工厂。然后，您向外观请求一辆具有这种或那种规格的汽车，并且外观应该知道要返回什么ICar实例来交换您要求它提供给您的东西。

无论如何希望这有帮助！ =)

Answer 2

如果我没记错的话，您会问两个问题：

1. 如何构建 DDD 应用程序？
2. 那些长命名空间名称怎么样？

我的答案相当冗长——我冒昧地将其分成两个答案。

这是第二个问题的答案：

2。那些长命名空间名称怎么样？

我不认为长命名空间名称一定是混乱的。
恕我直言，你的名字看起来很混乱的是：

• 重复使用“Product”和“Core”一词
• 通用术语“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;

此外，我发现使用商业产品名称（例如as MyProduct）在代码结构中很糟糕（如果营销选择不同的名称怎么办？）；我喜欢使用逻辑子系统的名称。
让我们假设您正在构建汽车租赁系统。那么CarRental将被视为此应用程序的核心功能。然后我将使用以下命名空间结构（Serra 是我公司的名称）：

// 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），您可以从单个程序集和单个名称空间开始。在开发过程中，您将看到如何更改项目结构以更好地满足您的需求。然后重构它。

请观看演讲，时间为 38:18-39:45（约 1.5 分钟）。关于如何回答一些问题有很好的实践。