问题标签 [domain-driven-design]

更新： 09/02/2009 - 修订问题，提供更好的示例，增加赏金。

嗨，
我正在使用数据库和实体（域对象）之间的数据映射器模式构建一个 PHP 应用程序。我的问题是：

封装通常执行的任务的最佳方法是什么？

例如，一项常见任务是从站点映射器检索一个或多个站点实体，并从页面映射器检索它们的关联（主页）页面实体。目前，我会这样做：

现在这是一个相当微不足道的例子，但实际上它变得更加复杂，因为每个站点也有一个关联的语言环境，并且页面实际上有多个修订版（尽管出于本任务的目的，我只对最近的一个感兴趣）。

我将需要在我的应用程序中的多个位置执行此操作（获取站点和关联的主页、区域设置等），并且我想不出封装此任务的最佳方式/位置，所以我不会必须到处重复。理想情况下，我希望得到这样的结果：

生成的站点实体已创建关联实体并可供使用。

保存这些对象时也会出现同样的问题。假设我有一个站点实体和关联的主页实体，并且它们都已被修改，我必须执行以下操作：

同样，微不足道，但这个例子被简化了。重复代码仍然适用。

在我看来，拥有某种可以处理的中心对象是有意义的：

• 检索一个（或多个）站点和所有必要的关联实体
• 使用新的关联实体创建新的站点实体
• 获取一个（或多个站点）并保存它和所有关联实体（如果它们已更改）

所以回到我的问题，这个对象应该是什么？

• 现有的映射器对象？
• 基于存储库模式的东西？*
• 基于工作模式的东西？*
• 还有什么？

*正如您可能猜到的那样，我不完全理解其中任何一个。

有没有解决这个问题的标准方法，有人可以提供他们如何实现它的简短描述吗？我不是在寻找任何人来提供一个完全有效的实现，只是理论。

谢谢，
杰克

假设我有一个实体 Foo，它包含另一个实体 Bar 的列表。Bar 应该直接引用 Foo 吗？IE..

还是我只是在我的 Bar 类中省略了对 Foo 的引用？

我倾向于忽略该参考，但想知道这里的正确方法是什么？

您如何处理域驱动设计中复杂聚合的验证？您是否正在整合您的业务规则/验证逻辑？

我了解参数验证，并且了解可以附加到模型本身的属性验证，并执行诸如检查电子邮件地址或邮政编码是否有效或名字具有最小和最大长度之类的操作。

但是涉及多个模型的复杂验证呢？您通常将这些规则和方法放在您的架构中的什么位置？如果有的话，你用什么模式来实现它们？

我一直试图围绕 DDD 以及它如何与 MVC 关联起来，但我在实体识别方面遇到了麻烦。

特别是，我试图保持我的表示、域和数据模型之间的严格分离。我的问题在于我如何跨这些边界保存实体标识。澄清一下，我使用不同的类来表示不同上下文中的同一实体 - 例如，我有一个“ShipmentRequest”域类、几个“ShipmentRequestView”表示类（取决于特定视图所需的属性）和一个'shipment_request' 数据库表（我的数据模型）。

我觉得使用“ID”属性（如 ShipmentRequestId）会违反我试图实现的分离，因为此 ID 属性是数据库问题，而不是域问题；而且我不想在层之间传递相同的对象，因为这意味着将不需要的数据传递到我的表示层。

我如何保持这种分离，同时跟踪这些层之间的身份？

我正在开始一个新项目，并决定尝试合并 DDD 模式，还包括 Linq to Entities。当我查看 EF 的 ObjectContext 时，它似乎正在执行存储库和工作单元模式的功能：

从实体表示抽象出底层数据级接口的意义上的存储库，我可以通过 ObjectContext 请求和保存数据。

从某种意义上说，我可以将所有插入/更新写入 objectContext 并在执行 SaveChanges() 时一次性执行它们。

将这些模式的另一层放在 EF ObjectContext 之上似乎是多余的？似乎模型类也可以使用“部分类”直接合并到 EF 生成的实体之上。

我是 DDD 的新手，所以如果我在这里遗漏了什么，请告诉我。

我是域模型、POCO 和 DDD 的新手，所以我仍在努力思考一些想法。

我还没有弄清楚的一件事是如何保持我的域模型简单且与存储无关，但仍然能够以丰富的方式对其数据执行一些查询。

例如，假设我有一个包含 OrdemItems 集合的实体 Order。无论出于何种原因，我都想获得最便宜的订单商品，或者可能是目前没有库存的订单商品清单。我不想做的是从存储中检索所有订单项目并稍后过滤（太昂贵），所以我想最终以某种方式获得“SELECT .. WHERE ITEM.INSTOCK = FALSE”类型的数据库查询。我不想在我的实体中使用该 SQL 查询，或者任何变体是否会将我绑定到特定平台，例如 Linq2SQL 上的 NHibernate 查询。在这种情况下，常见的解决方案是什么？

我还在纠结 DDD，我遇到的绊脚石之一是如何处理不同聚合之间的关联。假设我有一个封装客户的聚合和另一个封装发货的聚合。

出于业务原因，Shipments 是它们自己的集合，但它们需要明确地与客户相关联。我的客户域实体应该有一个货件清单吗？如果是这样，我如何在存储库级别填充此列表 - 假设我将有一个 CustomerRepository 和一个 ShipmentRepository（每个聚合一个 repo）？

我说的是“关联”而不是“关系”，因为我想强调这是一个领域决策，而不是基础设施决策——我首先从模型设计系统。

编辑：我知道我不需要将表直接建模为对象——这就是我首先设计模型的原因。在这一点上，我根本不关心数据库——只关心这两个聚合之间的关联。

示例接口：

我希望我的所有 EF 对象都在主键上实现这个接口。

这可能吗？

我已经开始学习 DDD 并且想知道其他人是如何组织他们的项目的。

我开始围绕我的 AggregateRoots 进行组织：

MyApp.Domain（域模型的命名空间）

MyApp.Domain.Product
- 产品
- IProductService
- IProductRepository
- 等

MyApp.Domain.Comment
- 评论
- ICommentService
- ICommentRepository
- 等

MyApp.Infrastructure
- ...

MyApp.Repositories
- ProductRepository : IProductRepository
- 等等

我遇到的问题是我必须将我的域产品引用为 MyApp.Domain.Product.Product 或 Product.Product。我还与产品的 linq 数据模型发生冲突......我必须使用丑陋的代码行来区分两者，例如 MyApp.Domain.Product.Product 和 MyApp.Respoitories.Product。

我真的很想看看其他人如何组织他们的 DDD 解决方案......

我使用 Visual Studio 作为我的 IDE。

非常感谢。

我一直在努力思考如何将我的域对象公开给客户端。无论我使用的是富客户端还是使用 Web，我都想使用 MVP 和存储库模式。

我想要了解的是如何公开我的存储库和模型，它们将在服务器上。是否可以通过 Web 服务公开具有状态的复杂业务对象，或者我是否必须使用与语言/平台无关的专有技术，如 .Net 远程处理、EJB、COM+、DCOM 等？

其他一些限制是我不想每次我想执行操作时都必须不断地从数据库中加载复杂的域对象或通过网络传递它。一些复杂的逻辑可能是屏幕的某些区域可能会根据用户权限以及对象的状态被禁用或不可见。验证和错误消息信息也需要显示给用户。我希望能够在逻辑上调用我的许多域对象操作，就好像它在同一台机器上运行一样。

有了网络，您就可以自由发挥。您不必跨服务边界公开您的对象，因此您可以根据需要使它们变得丰富。我正在尝试创建一个丰富的 N-teir 架构，当调用该模型的客户端在另一台机器上时它可以工作。