ドメイン駆動設計(DDD)ってなに？第6回：例外はバケツリレー？DDDっぽい設計と責任の渡し方

PHPの例外処理って、発生したところから順番に try を探して上に渡っていくじゃないですか。あれってまさにバケツリレーだな…と思っていて、個人的にすごくしっくりきたんです。

で、これって実はDDDの設計にもちょっとだけ関係あるんじゃないか？と思って調べてみたメモです。

例外は「誰が責任を持つか」の問題

DDDでは、役割ごとに責任が分かれています。

• ドメイン層（＝ルールそのもの）
• アプリケーション層（＝処理の流れ）
• インフラ層（＝実際の保存や通信）

なので、「このエラーは誰が持つべきか？」っていう判断がめちゃくちゃ大事らしい。

DDD的な例外の分け方（ざっくり）

バケツリレーで考える

たとえば在庫不足がドメイン層で発生したとき：

public function purchaseItem(User $user, Product $product)
{
    if ($product->stock < 1) {
        throw new InsufficientStockException();
    }
}

この InsufficientStockException は、ドメインのルール違反。
なので「おっと、それはルール違反ですね」と判断するのはアプリケーション層の役目です。

→ つまり「集約ルートで例外が発生 → アプリケーション層までバケツリレーで渡す」という構造。

そのまま catch しないとどうなる？

• コントローラーがそのまま 500 Internal Server Error を返してしまう
• ユーザーに伝わる内容が「エラーが発生しました」だけになる
• しかもログ見てもどこで発生したかわからない

→ だから「どこまでバケツを回して、どこで止めるか？」の設計が重要になる。

まとめ

例外処理ってPHPの機能だし、DDD専用の仕組みではないんですが、DDDっぽい設計を意識すると、「例外をどこで発生させ、どこで握るか？」という判断がとても重要なんだなと思いました。

• ドメイン層はルールに違反したときに「怒る」場所
• アプリケーション層はそれをキャッチして、次にどうするか判断する場所
• インフラ層で落ちるエラーは、もう少し技術的な世界のお話

そんなふうに、「バケツリレー」で責任をどう渡していくのかを意識することで、例外処理も少しずつ整理できる気がしました。