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

Question

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

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

Core
- DataAccess
--Impl
-Domain
-Impl

Core 是我的核心 API 库 - 我的 DLL。DataAccess 包含数据访问接口(interface)DataAccess.Impl 包含存储库(LINQ to the DB)域包含我的大部分数据类型和属性。Impl 包含我的服务(即 AccountService.cs、EmailService.cs)

现在，作为练习，我向这个项目添加了一个 Windows 服务并试图从该服务中的 DLL 调用功能。我的问题是，我应该向其他应用程序公开哪一层什么应该隐藏？

• Impl 文件夹中的服务类应该是程序员看到的吗？
• 或者来自 DataAccess.Impl 的存储库？
• 或者，我是否应该将所有内容都展示给程序员看？看起来现在，这似乎有点令人困惑。

当我开始阅读有关 DDD 的内容时，我假设存储库是被服务类隐藏和访问，但我发现我需要调用来 self 客户的功能。我设计错了吗？

我的另一个问题与 namespace 命名有关。当 Windows 服务从我的核心库调用功能，我必须这样做:

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

这看起来很啰嗦。查看 Microsoft 的 DLL，它们似乎保持两层惯例 -(System.Linq、System.Text 等)。拥有 Company.Product.ProductCore.Core.Impl看起来很乱，并没有真正告诉程序员这个命名空间的作用(但它是我阅读的示例所建议的)。这里有最佳实践吗？

非常感谢您的建议(和任何示例)。

谢谢。

Answer 1

域绝对不是您要找的，在我看来，您的数据访问层也不是。

以我的拙见，如果我们考虑 Façade 设计模式，它会公开您的库子系统的特性和功能，那么必须公开的内容还不存在，也就是说，静态类。

Façade 设计模式解释:

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

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

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

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

希望这对您有所帮助! =)