BDD/DDD在哪里放置基本实体验证的规范? [英] BDD/DDD Where to put specifications for basic entity validation?

问题描述

或者，基本实体验证是否被视为规范?

Alternatively, is basic entity validation considered a specification(s)?

通常，将基本实体验证(名称不能为null或为空，日期必须大于xxx)保留在实际实体中，还是在规范之外进行保留，会更好吗?

In general, is it better to keep basic entity validation (name cannot be null or empty, date must be greater than xxx) in the actual entity, or outside of it in a specification?

如果在规范中，它将是什么样?您会为每个字段制定一个规范，还是将其全部包装在一个EntityIsValid类型规范中?

If in a specification, what would that look like? Would you have a spec for each field, or wrap it all up in one EntityIsValid type spec?

推荐答案

在我看来，一旦人们对DDD有了一些了解，他们就会采用Specification模式并希望将其应用到任何地方.确实是 Golden Hammer 反模式.

It seems to me that once people have learned a little about DDD, they pick up the Specification pattern and look to apply it everywhere. That is really the Golden Hammer anti-pattern.

我看到规范模式的地方的方式以及我理解的方式

The way I see a place for the Specification pattern, and the way I understood Domain-Driven Design, is that it is a design pattern you can choose to apply when you need to vary a business rule independently of an Entity.

请记住，DDD是一种迭代方法，因此您不必在第一时间就将其正确".我将从将基本验证放入实体开始.这与有关OOD的基本思想非常吻合，因为它可以使代表概念的对象知道有效数据范围.

Remember that DDD is an iterative approach, so you don't have to get it 'right' in the first take. I would start out with putting basic validation inside Entities. This fits well with the basic idea about OOD because it lets the object that represents a concept know about the valid ranges of data.

在大多数情况下，您甚至不需要显式验证，因为应设计实体，以便将约束表示为不变量，从而无法创建违反约束的实例.

In most cases, you shouldn't even need explicit validation because Entities should be designed so that constraints are represented as invariants, making it impossible to create an instance that violates a constraint.

如果您有一条规则规定Name不能为null或为空，则可以直接在您的Entity中主动实施它:

If you have a rule that says that Name cannot be null or empty, you can actively enforce it directly in your Entity:

public class MyEntity
{
    private string name;

    public MyEntity(string name)
    {
        if(string.IsNullOrEmpty(name))
        {
            throw new ArgumentException();
        }
        this.name = name;
    }

    public string Name
    {
        get { return this.name; }
        set
        {
            if(string.IsNullOrEmpty(value))
            {
                throw new ArgumentException();
            }
            this.name = value;
        }
    }
}

名称不能为null的规则现在是该类的不变式:MyEntity类现在无法进入该规则被破坏的状态.

The rule that name cannot be null is now an invariant for the class: it is now impossible for the MyEntity class to get into a state where that rule is broken.

如果以后发现规则更复杂或在许多不同概念之间共享，则可以随时将其提取到规范中.

If later on you discover that the rule is more complex, or shared between many different concepts, you can always extract it into a Specification.

这篇关于BDD/DDD在哪里放置基本实体验证的规范?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！