ドメイン駆動設計の値オブジェクトのバリデーションはどこで処理すべきかで悩んでます。

Question

ドメイン駆動設計の値オブジェクトの作成時のバリデーションを
AppConfig.jsonから読み込んだ値を使用して評価処理を行う
仕様クラスを作成して実現しようと考えているのですが
その評価処理はどこで行うべきかで悩んでます。

具体的には下記のように名前属性のみ持つ値オブジェクトがあり、

public Class Person
{
    public string Name { get; }
    
    public Person(string name)
    {
        Name = name;
    }
}

その名前属性の最大文字数をAppConfig.json内から取得するためのクラスのインターフェースがあり、

public interface IAppConfigJsonReader
{
    int PersonMaxNameLength { get; }
}

上記のインターフェースを使用して下記のような名前の文字数の仕様クラスを作成しました。

public class PersonNameLengthSpecification
{
    private IAppConfigJsonReader _configReader;
    
    public PersonNameLengthSpecification(IAppConfigJsonReader configReader)
    {
        _configReader = configReader;
    }
    
    public bool IsSatisfiedBy(Person person)
    {
        var name = person.Name;
        var length = name.Length;
        var maxLength = _configReader.PersonMaxNameLength;
        return length <= maxLength;
    }
}

しかしこの仕様クラスを使って実際にIsSatisfiedByメソッドで
バリデーションを行う場所はどこがよいのでしょうか?

候補としては3つありますがそれぞれデメリットがあります。

1. アプリケーションサービスのユースケース内でファクトリーかnew演算子を用いてPersonを生成した直後に判定
2. ファクトリー内で判定処理を組みアプリケーションサービスのユースケース内でそのファクトリを使用してPersonを生成
3. 値オブジェクトのコンストラクタ内で判定

候補1では判定の判定処理の漏れが発生しそうな気がします。
候補2ではコンストラクタインジェクションが複雑化してしまいます。
候補3ではコンストラクタの引数にIAppConfigJsonReaderを含める必要ができてしまいます。

ほかにももっと良い方法があるのなら教えていただきたいです。

どうかよろしくおねがいします。

Comments

[Zuishin]

> 候補2ではコンストラクタインジェクションが複雑化してしまいます。

そうですか？
どのみちそのコードがどこかに入るなら複雑度は変わらないのでは？

私なら Person 専用のバリデータを作るのではなく、バリデートすべき仕様を ValidationAttribute から派生した属性として Person もしくはそのプロパティに与え、汎用バリデータを使用します。
例えば次のようなものです。

https://learn.microsoft.com/ja-jp/dotnet/api/system.componentmodel.dataannotations.stringlengthattribute?view=net-6.0

[退会済みユーザー]

「ドメイン駆動設計の値オブジェクト」とかは全く知らないのでハズレかもしれませんが・・・

どういうアプリで、何を、どういうタイミングで検証して、その結果で何がしたいのかによって「その評価処理はどこで行うべきか」は変わってくる、すなわち適材適所的なやり方があると思いますけど。

例えば（あくまで例えばですが）、Web アプリでユーザー入力の検証を行う場合、クライアント側で JavaScript による検証と、サーバー側での検証の両方を実装するのが普通ですが、「候補としては3つあります」の 3 つはどれも、特にクライアント側でのユーザー入力の検証には、不適切です。