3

または、基本的なエンティティの検証は仕様と見なされますか?

一般に、基本的なエンティティの検証 (名前は null または空にすることはできず、日付は xxx より大きくなければなりません) を実際のエンティティに保持するのと、仕様の外側に保持するのとではどちらがよいでしょうか?

仕様の場合、それはどのように見えますか? 各フィールドの仕様がありますか、それともすべてを 1 つの EntityIsValid 型の仕様にまとめますか?

4

2 に答える 2

4

ひとたび 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 クラスがそのルールに違反する状態になることは不可能になりました。

ルールがより複雑である、または多くの異なる概念間で共有されていることが後でわかった場合は、いつでもそれを仕様に抽出できます。

于 2009-10-03T09:05:24.583 に答える