domain-driven-design - 在 DDD/分层架构中存储常量的位置

Question

例如，我有一个 Media实体，它有 MediaType值对象，负责持有/创建媒体类型。存储可能的媒体类型常量列表的最佳位置是什么？首先我能想到的就是存储在 MediaType 里面因为它负责创建类型。但是如果我在应用层，或者在接口(interface)层需要它来验证请求，甚至在查询中呢？

看起来如果我想隔离域，我不能在 MediaType 中存储常量因为我不能在域外使用它。或者只在域层使用常量，并在其他地方对其进行硬编码，对我来说似乎不正确，因为在这种情况下我们没有一个地方可以更改它。第三个选项是创建单独的常量类，如 MediaConstants并将其存储在域之外(不确定在哪里)，但在这种情况下，我们似乎不需要 MediaType VO。

在 DDD 中处理常量的最佳实践是什么？

Answer 1

当然，隔离您的域是您所追求的。这意味着您的域包含所有相关的不变量，并且正如您所做的那样，包含使域模型具有表现力所需的枚举等。

有时，“外部”世界将需要各种重复，以使事情变得更容易和更方便。例如，您的域检查电子邮件地址的格式是否正确这一事实并不意味着您的 Web 前端也不会执行该验证。您可以在前端放弃这样的电子邮件验证，但这最终会给用户带来相当糟糕的体验。为了方便起见，我们“复制”了前端的验证。

一些数据也是如此。平面分类结构的通用方法可能类似于 ReferenceType 1-* ReferenceItem哪里ReferenceType.Name类似于 MediaType和 ReferenceItem.Name是您需要的任何值。有时你可能有一个 Code和 IsSystemType供您引用，但这是总体思路。每种引用类型都有一个或多个引用项，因此是一种相当简单的一对多关系，可以轻松地保存到某个数据存储中。然后，您可以通过查询机制向前端公开这些值，并且在您的集成层/关注点(Web Controller /消息处理程序)中，您可以获取相关的项目名称(或代码)并将其映射到例如您的枚举。