当前位置：文江博客话题详情

BDD/DDD 在哪里放置基本实体验证的规范？

发布于 2024-08-06 16:58:18 字数 167 浏览 1 评论 0原文

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

一般来说，将基本实体验证（名称不能为 null 或空，日期必须大于 xxx）保留在实际实体中还是在规范中保留在实体之外更好？

如果在规范中，那会是什么样子？您是否会对每个字段都有一个规范，或者将其全部包装在一个 EntityIsValid 类型规范中？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

甜嗑 2024-08-13 16:58:18

在我看来，一旦人们了解了一些 DDD，他们就会选择规范模式并希望将其应用到任何地方。这确实是金锤反模式。

我看待规范模式的方式，以及我理解领域驱动设计的方式的一个优点是，当您需要独立于实体改变业务规则时，您可以选择应用它的设计模式。

请记住，DDD 是一种迭代方法，因此您不必在第一次就将其“正确”。我首先将基本验证放入实体中。这非常符合 OOD 的基本思想，因为它让表示概念的对象了解数据的有效范围。

在大多数情况下，您甚至不需要显式验证，因为实体的设计应使约束表示为不变量，从而不可能创建违反约束的实例。

如果您有一条规则规定 Name 不能为 null 或为空，您可以直接在实体中主动强制执行该规则：

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;
        }
    }
}

name 不能为 null 的规则现在是该类的不变量：MyEntity 类现在不可能获取进入一种规则被打破的状态。

如果稍后您发现规则更复杂，或者在许多不同的概念之间共享，您始终可以将其提取到规范中。

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.

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.

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;
        }
    }
}

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.

回复收藏 0 原文