领域驱动设计：基础设施关注还是领域关注？答案

【问题标题】：Domain Driven Design: infrastructure concern or domain concern?领域驱动设计：基础设施关注还是领域关注？
【发布时间】：2016-05-27 10:49:55
【问题描述】：

我无法决定这是基础设施还是领域责任：

用户可以在 url 查询中传递日期范围，例如 dateStart=2016-04-12 ， dateEnd=2016-04-15。基于该日期范围，我们返回在这两个日期之间具有字段 createdOn 的实体列表。为了使这项工作正常，我必须将 2016-04-12 转换为 2016-04-12 00:00:00 和 2016-04-15 转换为 2016-04-15 23:59:59，这种转换是否应该被视为基础设施问题（并且应该放在存储库中，或者可能是应用层）或业务规则（并且应该放在服务或实体中）？

【问题讨论】：

理想情况下，您应该有一个服务类或库类，其中包含所有常用功能。例如，在这种情况下，一个名为 formatInputDate 的函数可能是一个您可以用来格式化日期的函数。
这似乎是一个数据约束，因为您的应用程序规则允许短 ISO 日期格式，而您的数据库仅支持长 ISO 日期格式。所以，它是一个数据库函数，应该放在数据访问层（或者存储过程/视图，如果你使用它们的话）。
DateRange 似乎是一个非常重要的概念。我将它建模为一个执行日期范围规则的值对象。日期范围的边界将由日期值定义。应用程序服务将接收字符串并创建一个DateRange。然后 DateRange 将被传递到存储库。然后，日期格式将在存储库中进行（委托给日期实用程序方法）。

标签： php oop domain-driven-design

【解决方案1】：

这种转换是否应该被视为基础架构问题（应该放在存储库中，或者可能是应用层）或业务规则（应该放在服务或实体中）？

正如 plalx 所指出的，DateRange/TimeInterval 本身可能是一个重要的概念，应该在模型中表示为值类型。

获取您获得的用户输入，并以您的模型表示的类型表示它们是应用程序关注的问题。

查找满足该约束的实体列表应该是存储库关注的问题。在您的存储库合同中明确说明该约束可能很有用 - 它用于记录您在底层存储中需要哪些功能。

【讨论】：

【解决方案2】：

我会创建一个Util 对象（类），它会为您提供转换器方法。
您必须决定如何在最深层（某种存储库？）中使用该格式。如果该格式与应用程序层上显示的格式不同，那么您必须在某处使用对话（我建议您的后端 API 的顶部），但准备好在存储库层等中使用验证。也是。

【讨论】：