域模型中域对象的集合

这可能是一个基本问题，但我对DDD很新颖。我有一个域对象，我们将其称为可以从UI批量处理的调整。在我们处理调整之前，我们需要验证这些调整将应用的日期。我的问题是在我的域对象中的IsValidDate（）方法的位置。域模型中域对象的集合

它应该是调整类中的静态方法吗？
它应该是AdjustmentService类的一部分吗？
我应该创建一个AdjustmentsGroup域对象来包含一系列调整，并且还会实现IsValidDate吗？

我会倾向于认为第三个选项是最好的选择，但我很难考虑调整对象组的领域术语。为这种类型的场景“强制”一个容器类型的域对象是否可以？有没有一种常见的做法来处理这个问题？

谢谢

编辑：IsValidDate实际上包含业务逻辑。这不仅仅是一个简单的日期验证方法

来源

2009-12-14 Benoit Martin

'AdjustmentsGroup'本身听起来像是一个很好的领域术语 - 假设没有其他聚合根是适合此集合的家（并且它对您的领域专家有意义）。 – 2009-12-14 20:21:08

不得不同意杰夫 - “AdjustmentsGroup”听起来像是一个自然适合与领域专家对话的术语。它还强制执行DDD的另一个原则：“明确隐含概念” – 2009-12-15 08:27:57

我会投票赞成2）让它成为DomainService。实现它的代码可以位于DomainServices类，AdjustmentServices类或ValidateAdjustmentService类中，具体取决于域模型中的其他服务，以及从组织角度最有意义的代码。

另一种选择（如果由该服务实现的规则是业务规则）是将其作为SPECIFICATION实现。（在DDD中查看第224-240页）

来源

2009-12-14 19:24:07

谢谢你的回答。验证日期是业务逻辑（我们正在验证我们是适当的日期范围，而不仅仅是日期是有效日期），所以我想知道是否选择2）并将该业务逻辑从域模型中取出是错误的方法？您在回答问题时是否将业务逻辑视为IsValidDate还是会影响您的答案？ – 2009-12-14 19:30:21

阅读规范的DDD概念。规范是判断一个对象是否满足某个标准的谓词。它现在是并且应该仍然是域模型的一部分，并且应该保留在模型中的域图层中。 – 2009-12-14 20:13:01

如果你正在做简单的is-this-actual-a-date字符串验证，那么在我看来，该方法的正确位置是在Service类中， Charles建议。然而，如果调整或调整集合对象内的数据可以改变日期验证逻辑，例如，不允许某些日期范围，该方法属于该对象。

来源

2009-12-14 19:29:05 iandisme

我赞成第三种选择，但是在调整时创建一个更通用的函数，如Validate（），它将返回一组错误/验证错误。这样，您可以在以后添加验证规则而无需更改界面。 AdjustmentsGroup的Validate（）函数只需在集合中的每个成员上调用Validate（）。一个同样有效的（不是双关语意图的）方式也可以为包含所有验证逻辑的对象具有单独的验证器类。

然后，您的AdjustmentService将在处理调整之前调用AdjustmentsGroup上的Validate（）。

来源

2009-12-14 19:29:10 ericvg

域模型中域对象的集合

回答

相关问题