使用 IoC 在 SOA 应用程序中使用 DDD 进行验证

Question

在我的服务外观层中，我有一个服务类，其方法/操作接受 DTO(数据契约)对象。 AutoMapper 用于将此 DTO 映射到我的域对象的实例中以应用任何更改。该请求被传递到我的域服务上，该服务执行实际工作。该方法可能如下所示:

public EntityContract AddEntity(EntityContract requestContract)
{
    var entity = Mapper.Map<EntityContract, Entity>(requestContract);

    var updatedEntity = Service.AddEntity(entity);

    var responseContract = Mapper.Map<Entity, EntityContract>(updatedEntity);

    return responseContract;
}

使用 Unity 作为 IoC 容器的构造函数注入(inject)来设置 Service 和 Mapper 属性。

在执行操作时，域服务对实体进行更改，然后使用存储库来保存更改，例如:

public Entity AddEntity(Entity entity)
{
    // Make changes to entity

    Repository.Add(entity);

    // Prepare return value
}

存储库也是使用构造函数注入(inject)设置的。

问题是数据一旦被持久化就立即可供其他客户端使用，因此我必须确保没有无效数据被持久化。我已经阅读了 DDD (Evans) 和 Nilsson 的“蓝皮书”，但不清楚我应该采用哪种验证方法。

如果我的目标是防止实体进入无效状态，我是否应该在我的服务方法中验证 entityContract 以确保在将请求传递到我的域服务之前满足所有规则？我对此犹豫不决，因为我似乎打破了在服务外观中定义这些规则的封装。

我们使用薄的外观层委托(delegate)给域服务的原因是我们在 API 中公开了粗粒度的接口(interface)，但通过组合细粒度的域服务来支持重用。请记住，多个外观服务可能会调用相同的域服务方法，也许将这些规则委托(delegate)给域服务会更好，这样我们就知道每次使用都经过验证。或者我应该在这两个地方进行验证？

我还可以在属性 setter 中设置保护，以防止 Not Acceptable 值将实体置于无效状态。这意味着 AutoMapper 在尝试映射无效值时会失败。但是，当没有映射任何值时，它没有帮助。

我仍然无法摆脱这些规则是实体行为的一部分的想法，并且确定对象是否有效应该封装在实体中。这是错的吗？

所以首先我需要确定何时何地执行这些验证检查。然后我需要弄清楚如何使用 DI 来实现依赖关系。

你能提供什么建议？

Answer 1

I've read the "blue book" of DDD (Evans) as well as Nilsson and am not clear what approach to validation I should take.

蓝皮书从不同的角度解决了这个问题。我认为没有使用“验证”一词，因为它是危险的 overgeneralization .更好的方法是考虑 对象不变量 ，而不是验证。对象(不仅在 DDD 中)应该自己强制执行它们的内部不变量。它不是 UI 或服务或契约(Contract)或映射器或“验证框架”或对象外部的任何其他东西。不变量在内部强制执行。您可能会发现这些答案很有帮助: 1 , 2 , 3 , 4 .

I could also put guards in the property setters that prevent unacceptable values from ever putting the entity into an invalid state. This would mean that AutoMapper would fail when trying to map an invalid value.

您可能根本不应该关心 AutoMapper 失败或使用 AutoMapper。域对象应该封装并强制执行它们的内部不变量，如果尝试破坏它，则抛出异常。它非常简单，您不应该因为一些基础设施问题而损害域对象的简单性和表现力。 DDD 的目标不是满足 AutoMapper 或任何其他框架的要求。如果该框架不适用于您的域对象，请不要使用它。