DDDの例外

私はDDDを学んでいて、特定の状況で例外をスローすることを考えています。私はオブジェクトが悪い状態に入ることができないことを理解しているので、ここで例外は問題ありませんが、多くの例では、たとえば、データベースに電子メールが存在する新しいユーザーを追加しようとした場合にも例外がスローされます。

public function doIt(UserData $userData)
{
    $user = $this->userRepository->byEmail($userData->email());
    if ($user) {
        throw new UserAlreadyExistsException();
    }

    $this->userRepository->add(
        new User(
            $userData->email(),
            $userData->password()
        )
    );
}

したがって、この電子メールを持つユーザーが存在する場合、アプリケーションサービスで例外をキャッチできますが、try-catchブロックを使用してアプリケーションの操作を制御するべきではありません。

これに最適な方法は何ですか？

問題空間の簡単な復習から始めましょう。DDDの基本的な原則の1つは、ビジネスルールを適用する必要のある場所にできるだけ近づけることです。これは非常に重要な概念であり、システムをより「まとまり」のあるものにします。ルールを「上向き」に移動することは、一般的に貧血モデルの兆候です。ここで、オブジェクトは単なるデータのバッグであり、ルールには適用されるデータが注入されます。

貧血モデルは、DDDを使い始めたばかりの開発者には非常に理にかなっています。メールを検証するために必要な情報が注入されるUserモデルとを作成EmailMustBeUnqiueRuleします。シンプル。エレガント。問題は、この「一種の」思考が根本的に手続き型であるということです。DDDではありません。何十ものRulesきちんとラップされてカプセル化されたモジュールが残されてしまいますが、いつどこで適用されるかが明確ではないため、変更できなくなるところまで完全にコンテキストがありません。それは理にかなっていますか？それは可能という自明のこと EmailMustBeUnqiueRuleの作成時に適用されますUserが、何についてUserIsInGoodStandingRule？。ゆっくりだが確実に、抽出の粒状化Rulesそれらのコンテキストから外れると、理解しにくい（したがって変更できない）システムが残ります。ルールは、実際のクランチ/実行が非常に詳細であり、モデルがフォーカスを失い始めた場合にのみカプセル化する必要があります。

今すぐあなたの特定の質問へ上：持つ問題Service/ CommandHandlerスローExceptionビジネスロジックは、自分のドメインのうち、（「上向き」）リークし始めているということです。なぜ、あなたのんService/ CommandHandler電子メールを知る必要は一意である必要がありますか？アプリケーションサービスレイヤーは通常、実装ではなく調整に使用されます。この理由は、ChangeEmailメソッド/コマンドをシステムに追加した場合に簡単に説明できます。これで、メソッド/コマンドハンドラーの両方に独自のチェックを含める必要があります。これは、開発者がを「抽出」したくなるかもしれない場所EmailMustBeUniqueRuleです。上で説明したように、そのルートには行きたくありません。

追加の知識を駆使すると、より多くのDDD回答が得られます。電子メールの一意性は不変であり、Userオブジェクトのコレクション全体に適用する必要があります。ドメインに「Userオブジェクトのコレクション」を表す概念はありますか？たぶん私がどこに行くのかわかると思います。

この特定のケース（およびコレクション全体で不変条件を適用することを含む多くのケース）では、このロジックを実装するのに最適な場所はRepositoryです。これはRepository、この種の検証を実行するために必要な追加のインフラストラクチャ（データストア）も "知っている" ため、特に便利です。あなたの場合、私はaddメソッドにこのチェックを入れます。これは理にかなっていますか？概念的にはUser、システムにを追加するのはこの方法です。データストアは実装の詳細です。

アプリケーションのすべての層に検証を課すことができます。アプリケーションに依存するルールを課す場所。

たとえば、エンティティはビジネスルールを表すメソッドを実装し、ユースケースはアプリケーションに固有のルールを実装します。

Gmailのような電子メールサービスを構築している場合、「ユーザーには一意の電子メールアドレスが必要です」というルールはビジネスルールであると主張できます。

新しいCRMシステムの登録プロセスを構築する場合、このルールはユースケースの一部である可能性が高いため、このルールはユースケースで実装するのが最適です。さらに、ユースケーステストでリポジトリの呼び出しを簡単にスタブできるので、テストが簡単になる場合もあります。

追加のセキュリティのために、このルールをリポジトリに適用することもできます。