DDD对象验证

Question

我们正在建立一个房地产门户网站。我们有服务，Mappers和Entites。在阶段，我们允许用户

1. 通过表单创建属性。
2. 上传包含一个或多个属性的批处理文件。

因此，如果他通过表单创建属性，我们可以验证表单，如果它是有效的属性，我们可以将它添加到我们的系统中。但如果他通过批处理文件上传，我们认为表单的责任是

• 验证用户是否提供了文件
• 文件类型有效
• 且文件大小在允许的限制范围内。

在此之后，它应该将文件移交给控制器或服务。

现在待处理的任务是

• 处理文件并检索内容
• 验证内容
• 如果已验证，请保存属性或显示错误。

那么哪个部分负责上述任务？

我在想控制器应该进行初始文件处理并将数据传递给服务。这意味着我们将在控制器中创建/获取表单对象并验证控制器中的表单。

现在，下一部分将验证内容，实际上是实体的集合。所以我们对这个阶段有如下想法

1. 服务将验证数据并创建实体，它将保存它们。
2. 或者服务将使用提供的数据创建实体，然后调用实体的验证功能。
3. 或者服务将尝试使用提供的数据创建实体（将数据发送到实体构造函数），如果数据有效，将创建实体或生成错误等。

我可以考虑上述方法的可能问题是

• 如果服务正在验证数据，则意味着服务将知道实体的内部结构，因此如果我们需要更新实体结构，我们也必须更新服务。这将引入某种依赖。
• 在第二种方法中，如果实体无效，我认为不应该在第一时间创建实体。
• 在第3种方法中，我们在实体的构造函数中创建一个功能，因此使实体依赖于数据。因此，当我们需要从持久化中获取实体时，我们需要提供一些存根数据。

还是我过度思考？

Answer 1

  

现在，下一部分是验证内容，实际上是实体的集合。

内容，控制器发送到服务，是最简单情况下的对象/结构/普通字符串的图形，但绝不是商业实体的集合。

  

如果服务正在验证数据，则意味着服务将知道实体的内部结构

服务验证究竟是什么？

服务正在验证数据意味着服务可确保其收到的每个结构/对象不变。

例如，如果F(T)是服务方法而T是具有属性{ A, B, C }的结构，表示具有三条边的三角形，那么服务必须确保这个结构的不变量（每个站点的长度大于零和任何两个边的长度之和必须大于第三边的长度）在这个结构被反序列化之后。

必须完成此验证，因为反序列化器在反序列化期间不使用构造函数来确保不变量。

完成这些验证后，传递给服务的所有对象都有效，可以直接在业务层中自由使用，也可以转换为业务层已知的对象（例如实体）。

  

如果我们需要更新实体结构，我们也必须更新服务。这将引入某种依赖。

这种依赖性是不可避免的。由于传输对象和实体对象是分开的，因此始终存在知道如何转换它们的映射器。

  

服务将验证数据并创建实体，它将保存它们。

我会选择这个。服务验证数据，转换为业务层对象，调用业务层功能，持续更改。

Answer 2

这取决于您正在验证的约束类型。

1.参数验证，如notEmpty属性名称或最大长度等。

在这种情况下，您可以将验证逻辑提取到Validator对象。当您有多个属性创建表单（Web表单，文件上载）时，这很有用，验证程序可能由多个“客户端”调用，但验证逻辑保留在一个对象中。

2.业务规则验证。

我更喜欢使用域模型，您可以查看此presentation

中的PhoneNumber示例