ドメインイベントでビジネスロジックを解きほぐす #phpcon_odawara

PHPカンファレンス小田原2026の登壇資料です。

Transcript

2. 梶川 琢馬 𝕏 @kajitack 株式会社 TechBowl VPoT TechTrain の開発やメンターを担当してます！ 関数型まつりコアスタッフ コミュニティかわらばんに出展してます！ X でスライド公開してます！ https://x.com/kajitack 2/36
4. 今日のゴール ① メソッド分割の限界を「結合度」で理解する ② ドメインイベントでリファクタリングする方法を知る ③ 同期→非同期の段階的な導入ステップを知る 4/36
5. ある処理を変更したら 関係ない処理まで動かなくなった 5/36
6. ユーザー登録のよくあるコード 適切にメソッドが分割されていて、見通しの良いコード？ メール送信の仕様が変わるだけで、ユーザー登録全体のテストが壊れる class UserController { public function create($userData) { $user = new User($userData['email'], $userData['name']); $this->userRepository->save($user); $this->mailService->sendWelcomeEmail($user); // メール送信 $this->notificationService->notifyAdmin($user); // 運営に通知 $this->planService->createFreePlan($user); // 契約プラン作成 $this->externalService->syncUser($user); // 外部連携 } } 6/36
7. 分割しても依存構造は変わらない 呼び出し側が全ての処理を知っている 7/36
8. なぜ分割しても 解決しないのか 8/36
9. 結合度(Coupling) コンポーネント間の依存関係の強さ。結合度が高いと変更が連鎖する 疎結合にすれば、変更の影響をそのコンポーネント内に閉じ込められる 密結合（⾼結合） コンポーネント同⼠が互いを直接知っている 疎結合（低結合） コンポーネント同⼠が互いを知らない コンポーネントA ▲ 変更が発⽣ コンポーネントB コンポーネントC コンポーネントD A の変更 → B, C, D すべてに影響 修正・テストが連鎖的に必要になる コンポーネントA ▲ 変更が発⽣ コンポーネントB コンポーネントC インターフェース / イベント A の変更 → C, B には影響しない インターフェース経由で独⽴を保つ 9/36
10. 結合度の2つの軸: 振る舞い × 時間 メソッド分割では右上のまま。ドメインイベントで左上→左下へ段階的に移動できる 振る舞い的結合（統合強度） 時間的結合 コントラクト結合 事実の通知 機能結合 振る舞いの指⽰ 低 ⾼ 機能結合 ̶ 呼び出し側が仕事を知っている 巨⼤メソッド メソッド分割 サービス分割 Step 0 分割しても 結合の種類は変わらない コントラクト結合 ̶ 事実だけを共有する 同期イベント 振る舞い的結合を解消 時間的結合は残る ⾮同期イベント 両⽅の結合を解消 Step 1 機能結合 → コントラクト結合 Step 2 同期 → ⾮同期 10/36
11. 「振る舞い」を指示するか、「事実」を通知するか 「コマンド（これから実行すべき操作を表現したメッセージ）」 「イベント（すでに起こった変化を表現した事実）」 コマンド型 「メールを送れ」と指⽰ UserController sendEmail() notifyAdmin() createPlan() 送信側が受信側の仕事を知っている 振る舞い的結合が残る イベント型 「ユーザ���が作成された」と通知 UserController UserCreatedEvent MailSubscriber NotifySubscriber PlanSubscriber 送信側は受信側の存在を知らない 振る舞い的結合を断ち切れる 11/36
12. ドメインイベントとは 業務領域で発生した重要な出来事を表現するメッセージ 過去形で表現される取り消せない事実 「ユーザーが登録された」「注文が確定した」「在庫が切れた」 出来事を説明するために必要なデータを含む 12/36
13. ドメインイベント分析 ビジネス側の「〜したら」「〜のとき」という 言葉がヒント 1. 事業活動の出来事を過去形で洗い出す 2. 時系列に並べ、分岐や代替シナリオも整理する 3. イベントを引き起こす 「コマンド」や境界を発見する 13/36
14. Publisher と Subscriber Publisher は「何が起きたか」を発行するだけ Subscriber は関心のあるイベントだけを受け取る Publisher UserCreateUsecase イベントを発⾏する publish Event UserCreatedEvent 「何が起きたか」の通知 Subscriber handle MailSubscriber NotifySubscriber PlanSubscriber Publisher → Subscriber の 直接のつながりはない Publisher と Subscriber はイベントだけを共有し、 互いの存在を知らない 14/36
15. 依存の方向が逆転する Before ユーザー登録が 全ての副作用を呼び出す After 各処理が イベントに反応する 15/36
16. Before: 副作用の数だけモックが必要 #[Test] public function ユーザーを作成する() { $repo = $this->mock(UserRepository::class); $mail = $this->mock(MailService::class); $notification = $this->mock(NotificationService::class); $plan = $this->mock(PlanService::class); $external = $this->mock(ExternalService::class); // 全てのモックに期待値設定... $repo->expects($this->once())->method('save'); $mail->expects($this->once())->method('sendWelcomeEmail'); // ...副作用が増えるたびにモックも増える } 16/36
17. After: イベント発行の確認だけ 副作用が増えてもこのテストは変わらない #[Test] public function ユーザーを作成する() { $this->mock(DomainEventPublisher::class) ->expects($this->once()) ->method('publish'); app()->make(UserCreateUsecase::class) ->exec(new UserId('1'), new Email('test@example.com')); } 17/36
18. 振る舞い的結合は ドメインイベントで解きほぐす メソッド分割: 見通しは良くなるが、振る舞い的結合は残る ドメインイベント:「事実の通知」で振る舞い的結合を断ち切る → 依存の方向が逆転し、テストと変更がそれぞれ独立に 18/36
19. 同期ドメインイベント → 非同期化の2ステップ 19/36
20. Step 1: ドメインイベントで 振る舞い的結合を解消 同期処理のまま、依存の方向を逆転させる 振る舞い的結合（統合強度） 時間的結合 コントラクト結合 事実の通知 機能結合 振る舞いの指⽰ 低 ⾼ 機能結合 ̶ 呼び出し側が仕事を知っている 巨⼤メソッド メソッド分割 サービス分割 Step 0 分割しても 結合の種類は変わらない コントラクト結合 ̶ 事実だけを共有する 同期イベント 振る舞い的結合を解消 時間的結合は残る ⾮同期イベント 両⽅の結合を解消 Step 1 機能結合 → コントラクト結合 Step 2 同期 → ⾮同期 20/36
21. Subscriber Publisher Repository Domain Model Usecase Subscriber Publisher Repository Domain Model Usecase インスタンス作成 イベント作成 Publisher の登録 永続化処理 ドメインイベントを取得 イベントの発⾏ イベントを受け取る ドメインイベントの流れ 1. ドメインモデルがイベントを生成・保持する 2. 永続化した後にイベントを 取り出し、Publisher で発行する 3. Subscriber がイベントに反応して処理を実行する 同期/非同期の違いは Subscriber の実行タイミング 21/36
22. Before: 全ての副作用を直接呼び出す Usecase が 3 つのサービスに依存。1 つ変わればテストも修正が必要 class UserCreateUsecase { public function exec(UserId $userId, Email $email): void { $user = User::create($userId, $email); DB::transaction(function () use ($user) { $this->userRepository->save($user); }); // 副作用を全て知っている $this->mailService->sendWelcomeMail($user->email()); $this->notificationService->notifyAdmin($user); $this->planService->createFreePlan($user->id()); } } 22/36
23. After: イベントを発行するだけ Usecase は副作用を知らない。イベントへ反応する Subscriber が独立に処理する class UserCreateUsecase { public function exec(UserId $userId, Email $email): void { $user = User::create($userId, $email); DB::transaction(function () use ($user) { $this->userRepository->save($user); // 永続化後にイベントを発行するだけ foreach ($user->pullDomainEvents() as $event) { $this->eventPublisher->publish($event); } }); } } 23/36
24. Subscriber: イベントに反応する独立したクラス お互いに疎結合で、ドメインイベントにのみ依存 class WelcomeMailSubscriber { public function handle(UserCreatedEvent $event): void { $this->mailService->sendWelcomeMail($event->email()); } } class CreatePlanSubscriber { public function handle(UserCreatedEvent $event): void { $this->planService->createFreePlan($event->userId()); } } 24/36
25. 同期処理だけで テスト・変更・依存が改善する Before テスト: モック N 個 変更: 副作用追加で Usecase を修正 依存: Usecase が全サービスに依存 After テスト: モック 1 個 変更: Subscriber を追加するだけ 依存: EventPublisher のみに依存 25/36
26. Step 2: Subscriber の実行タイミングを変える ユーザーはイベント発行後すぐにレスポンスを受け取れる → 時間的結合の解消 振る舞い的結合（統合強度） 時間的結合 コントラクト結合 事実の通知 機能結合 振る舞いの指⽰ 低 ⾼ 機能結合 ̶ 呼び出し側が仕事を知っている 巨⼤メソッド メソッド分割 サービス分割 Step 0 分割しても 結合の種類は変わらない コントラクト結合 ̶ 事実だけを共有する 同期イベント 振る舞い的結合を解消 時間的結合は残る ⾮同期イベント 両⽅の結合を解消 Step 1 機能結合 → コントラクト結合 Step 2 同期 → ⾮同期 26/36
27. 非同期化の手段: メッセージングパターン Publisher が受信者を知らない構造なので Pub/Sub パターンが適している Point-to-Point Queue 1 対 1 で確実に届ける Producer Queue Consumer 特定の処理に確実に届けたい場合 例: ジョブキュー、タスク分散 Pub/Sub 1 対多でイベントを配信 Publisher Topic Sub A Sub B Sub C ドメインイベントの配信に最適 例: ユーザー作成 → メール、通知、プラン 27/36
28. 非同期化の問題: ロールバック時に イベントだけ残る DB コミットとイベント発行が別タイミングになる ロールバックしたのにイベントだけ発行されてしまう → データは無いのに Subscriber が動いてしまう 28/36
29. 解決: イベントを DB に保存する （Transactional outbox パターン） DB トランザクション内にイベントも保存し、別プロセスで配信する ロールバックすればイベントも一緒に消える → 整合性を保証 29/36
30. Outbox パターンのコード例 別プロセス（バッチ/ワーカー）が未処理イベントを取り出して配信する 同じトランザクションに入れるだけで、DB コミットとイベント配信の整合性を保証できる class UserRepository { public function save(User $user): void { DB::transaction(function () use ($user) { $this->dao->save($user); // 同じトランザクションでイベントも保存 foreach ($user->pullDomainEvents() as $event) { $this->eventStore->save($event); // イベントテーブルにINSERT } }); } } 30/36
31. DBに保存したイベントをバッチ処理でpublish Subscriber Pub/Sub Batch Event Store (DB) Subscriber Pub/Sub Batch Event Store (DB) 未処理イベントを取得 (status = 'pending') UserCreatedEvent のリスト メッセージを送信 (Topic: user-events) メッセージを送信 (Topic: user-events) イベントを処理済みにマーク (status = 'processed') 31/36
32. 適切な粒度でドメインイベントを 発行し、メッセージの順序を守る 顧客管理 UserCreated 販売促進 広告最適化 AdOptimized レポート出⼒ レポート出⼒が必要なのは UserCreated ではなく AdOptimized 正しいドメインイベントに反応すれば順序依存は⽣まれない 32/36
33. 段階的に進める 同期処理だけでも十分価値がある 非同期化は必要になってから Step 1: 同期処理 振る舞い的結合を解消 導入コストが低い すぐに始められる Step 2: 非同期化 時間的結合も解消 パフォーマンス改善 注意: 整合性→Outbox、重複→冪等性、順序→正しい イベントへの反応 33/36
34. ドメインイベントで ビジネスロジックを解きほぐす ビジネスロジックを「結合」の観点から見直し、 「ドメインイベント」で段階的に整理する ドメインイベント:「事実の通知」で依存の方向を逆転。各 Subscriber が独立して動き、追加は Subscriber を足すだけ。 変更も Subscriber に閉じ、テストのモックも激減する。 ドメインイベントの非同期化: 重い処理の時間的な依存を 解消する。整合性・重複・順序の課題には Outbox・冪等性・ 順序非依存、補償トランザクションで対処。ドメインイベントを 同期的に処理するだけでも振る舞いの結合は解消されるので、 段階的に進める。 34/36
35. 参考資料 「実践ドメイン駆動設計」Vaughn Vernon 著 / 髙木正弘訳 「ドメイン駆動設計をはじめよう」Vlad Khononov 著 / 増田亨監訳 / 黒田樹訳 「ソフトウェア設計の結合バランス」Vlad Khononov 著 / 島田浩二訳 35/36