メッセージングを利用して時間的結合を分離しよう #phperkaigi

PHPerKaigi2026の登壇資料です。

①「時間的結合」という概念を知る
② メッセージングで分離する方法を知る
③ 非同期処理による注意点と解決パターンを知る

https://fortee.jp/phperkaigi-2026/proposal/5ea64c6c-3726-4324-ab59-3c321f1a86ae

Transcript

2. ゴール ①「時間的結合」という概念を知る ② メッセージングで分離する方法を知る ③ 非同期処理による注意点と解決パターンを知る 2/44
3. 梶川 琢馬 𝕏 @kajitack 株式会社 TechBowl エンジニアの学習プラットフォーム TechTrain の開発や メンターをやってます 3/44
5. 良いアーキテクチャ？ 変化容易性 理解容易性 テスト容易性 観測可能性 組織適合性 経済合理性 今日は共通する考え方の「結合度」について Robert C. Martin The Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 5/44
6. 結合度 Coupling、カップリング コンポーネント(関数やクラスのまとまりなど)の 依存関係の強さ 結合度が適度に低いと良い設計(疎結合) 6/44
7. 結合度が高いと？ 「変更の難易度を上げ、システムの柔軟性と 信頼性を低下させる」 コンポーネントに変更を加えた場合、依存している 他のコンポーネントも一緒に変更やテストを しなければならない頻度が高くなる レイヤーやクラスや関数などの境界を定義して、 必要に応じて疎結合にするのが良い 7/44
8. 良い結合を目指す 本来密接に連携すべきコンポーネントまで無理に 引き剥がして疎結合にしようとすると、変更のたびに 複数のサービスをまたいだ複雑な調整が必要になり、 「分散した巨大な泥団子」という悲惨な アーキテクチャに終わる。 ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 Vlad Khononov　著/島田 浩二　訳 8/44
9. ふるまい的結合と時間的結合 ふるまい的(Behavioural)結合 コードの静的な依存 import や継承、呼び出しによる依存関係 例: OrderService が PaymentAPI と MailAPI に依存 時間的(Temporal)結合 実行タイミングの依存 外部 API の完了を待つ 例: 決済 API が遅れるとユーザーも待つ Temporal and Behavioural Coupling - Ian Robinson https://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/ 9/44
10. ふるまい的結合 (Behavioural Coupling) 送信側が何をするかを決定し、さらに 受信側がそのリクエストをどのように 処理するかを知っている 10/44
11. 時間的結合（Temporal Coupling） 厳格に順番どおりの処理が必要な場合や処理結果が後の処理へ繰り越される場合、 リクエストに対する反応が返ってくるまで後続の処理が開始できない。 function placeOrder(OrderRequest $request): OrderResponse { $order = $this->createOrder($request); // 注文作成 $this->paymentService->charge($order); // 決済API（外部: 1〜3秒） $this->mailService->sendConfirmation($order); // メール送信（外部: 0.5〜2秒） $this->pdfService->generateReceipt($order); // PDF生成（重い: 1〜3秒） return new OrderResponse($order); // 合計: 3〜10秒...ユーザーは画面の前で待っている } 11/44
12. 時間的結合を理解する 12/44
13. 時間的結合あるある 外部APIの呼び出し、重い内部処理 決済 API・メール送信など外部サービスの応答速度や重い処理に メインフローが縛られる。何らかの障害が起きたときに処理が止まる ユーザーがその場で結果を必要としていないか？ 失敗してもリトライで回復できるか？ 多少の遅延が許容されるか？ 予約確定後の通知、ファイルのアップロード処理、外部サービスとのデータ同期など。 13/44
14. 非同期処理のメリット ユーザーへのレスポンスが速くなる 時間のかかるシステムだけスケールさせてパフォーマンスを得られる トランザクションの範囲を狭くすることができる 14/44
15. 同期処理で行うべき リソースの確保と解放 できる同じ順序で実行される必要 DB の接続やトランザクション制御 条件の確認や状態遷移 与えられた入力が正しいか、DB に問い合わせる 入力を元に注文オブジェクトを組み立てる 注文作成時に在庫チェック後、注文確定 実行する順序が重要なものは同期処理で行う 15/44
16. メッセージングで 時間的結合を分離する 16/44
17. メッセージングの仕組み キューや Pub/Sub など メインフローはキューに積んだ時点で 完了。残りは別プロセスが処理する。 送信者と受信者の間の仲介し、お互いの 動作に影響を与えない。 17/44
18. Before（全部同期） function placeOrder($req): OrderResponse { $order = $this->createOrder($req); $this->inventory->reserve($order); $this->payment->charge($order); // ↓ ここから先がユーザーを待たせている $this->mail->sendConfirmation($order); $this->pdf->generateReceipt($order); $this->notification->notifyAdmin($order); return new OrderResponse($order); } 6 つの処理が全部直列。ユーザーは外部 API の完了を待つ 18/44
19. After（メッセージング導入） function placeOrder($req): OrderResponse { $order = $this->createOrder($req); $this->inventory->reserve($order); $this->payment->charge($order); // 「注文を確定したイベント」をメッセージ $this->eventPublisher->publish( new OrderConfirmed($order) ); return new OrderResponse($order); // ← ここで即座にレスポンス } 19/44
20. 送るメッセージの違い コマンド型、イベント型 20/44
21. コマンド型 指示するメッセージ 「メールを送れ」 呼び出し側が仕事を決めているため、振る 舞い的結合が残る 21/44
22. イベント型 ドメインイベントを使った、事実を 伝えるメッセージ 時間的結合だけでなく、ふるまい的結合も 同時に解消できる 22/44
23. イベントによる、ふるまい的結合の解消 イベントの発行と副作用のテストを分けることができ、テストが書きやすくなる #[Test] public function ユーザーを作成する() { // ユーザー作成時にイベントが発行されることを確認 $this->mock(DomainEventPublisher::class) ->expects($this->once()) ->method('publish'); app()->make(UserCreateUsecase::class)->exec($input); } #[Test] public function ウェルカムメールを送信する(): void { $mailService = $this->mock(MailService::class); $mailService->expects($this->once()) ->method('sendWelcomeMail') ->with($this->equalTo(new Email('user@example.com'))); $event = new UserCreatedEvent( new UserId('123'), new Email('user@example.com') ); app()->make(WelcomeMailSubscriber::class)->handle($event); } 23/44
24. ドメインイベントを使った実装 24/44
25. ドメインイベントとは ドメイン = 扱っている事業・業務領域 EC サイト：商品・注文・決済 SNS：ユーザー・投稿・フォロー ドメインで発生する「出来事」を表現するモデル 「ユーザーが登録された」 「注文が確定した」 「在庫が切れた」 25/44
26. イベントの洗い出し 「ユーザーが登録された時」に「ウェルカムメールを送りたい」 「ユーザーが登録された時」に「運営に通知したい」 「ユーザーが登録された時」に「契約プランを作成したい」 → ビジネス側の「〜したら」「〜のとき」という言葉がドメインイベントのヒント 26/44
27. イベントを 図にまとめる 重要なビジネスイベントを洗い出し、 コンテキストごとにまとめる TechBowl流ドメインモデルでの情報設計 https://speakerdeck.com/hiroki_nakamura/techbowlliu-domeinmoderingu-2025-02-28 ドメインモデルの管理にYAMLを使ってみた https://zenn.dev/techtrain_blog/articles/cf6e9ce3634d51 27/44
28. イベントを 中心に実装 Publisher（パブリッシャー） イベントを発行 Subscriber（サブスクライバー） イベント発行時に処理を実行 28/44
29. Subscriber Publisher Repository Domain Model Usecase Subscriber Publisher Repository Domain Model Usecase インスタンス作成 イベント作成 Publisher の登録 永続化処理 ドメインイベントを取得 イベントの発⾏ イベントを受け取る ドメインイベントの 発行と処理の流れ 1. ドメインオブジェクトで ドメインイベントを作成と保持 2. 永続化した後にドメインイベントを 取り出し、パブリッシャーで発行 3. サブスクライバーでイベントの 通知を受け取って処理 29/44
30. ドメインイベントを作成する 「ユーザー作成時」に「ユーザーが作成された」イベントを作成し、保持する class User implements IDomainEventStorable { use DomainEventStorable; public static function create(UserId $userId, Email $email): self { $user = new self($userId, $email); // ドメインイベントを内部に保持 $user->pushDomainEvent(new UserCreatedEvent($userId, $email)); return $user; } } 30/44
31. パブリッシャーとサブスクライバー ドメインイベントをサブスクライバーに発行する処理を実装 final class UserCreatedEventPublisher { public function __construct( WelcomeMailSubscriber $mailSubscriber, CreateBillingAccountSubscriber $billingSubscriber, SendChatNotificationSubscriber $notificationSubscriber, ) { // コンストラクタでsubscribersに追加する } public function publish(DomainEvent $event): void { foreach ($this->subscribers as $subscriber) { $subscriber->handle($event); } } } class WelcomeMailSubscriber { public function handle(UserCreatedEvent $event): void { // イベントに応じた処理を実行 $this->mailService->sendWelcomeMail($event->email()); } } 31/44
32. 永続化のタイミングでイベント発行 リポジトリでドメインイベントをパブリッシュしなければいけないということを明示的にする class UserCreateUsecase { public function exec(UserId $userId, Email $email): void { // ドメインモデルを生成（ここでイベントが内部的に作成される） $user = User::create($userId, $email); DB::transaction(function () use ($user) { //　パブリッシャーの登録 $this->userRepository->create($user, $this->eventPublisher); }); } } class UserRepository { public function create( User $user, UserCreatedEventPublisher $eventPublisher ): void { $this->dao->save($user); // 永続化後にイベントの発行 foreach ($user->pullDomainEvents() as $event) { $eventPublisher->publish($event); } } } 32/44
33. 非同期処理での注意点 33/44
34. 最悪のケースを想定する DB とメッセージ送信の整合性のズレ メッセージの重複 メッセージが順番通りに届かない 34/44
35. 課題1: 整合性のズレ 何らかの理由でロールバックしてしまった際に、 データは無いのにイベントだけ発行されてしまう... 「ドメインの状態更新」と「外部への通知」が 別タイミングになる DB::transaction(function () use ($user) { $this->userRepository->save($user); // DB保存 成功 }); // トランザクションの外 $this->messageQueue->publish( // 送信 失敗！ new UserCreated($user) ); // → ユーザーは保存されたが、ウェルカムメールが永久に届かない 35/44
36. Transactional Outbox パターン 同じトランザクション = 両方とも成功 or 失敗 DB::transaction(function () use ($user) { // ユーザーの保存 $this->userRepository->save($user); // 同じトランザクション内にメッセージを保存 $this->outboxRepository->store( new OutboxMessage( eventType: 'UserCreated', payload: json_encode(['userId' => $user->id, ...]), status: 'pending', ) ); }); 36/44
37. Outbox から メッセージキューへ配信 別プロセスが定期配信 (cron など) 失敗してもメッセージは残る 次回のポーリングで再配信 37/44
38. Consumer Queue Publisher Consumer Queue Publisher 「未処理」と判断 結果: メールが2 通届く ポイントが⼆重付与される [OrderConfirmed] 配信 処理成功 ✅ ACK 失敗 再配信 🔁 2 回⽬の処理... 課題2: メッセージの重複 ネットワーク障害後の再送で、同じ メッセージが複数回届く 結果: メールが 2 通届く、ポイントが 二重付与される... 38/44
39. 処理済みかどうかをマークする function handleUserCreated(UserCreated $event): void { // 冪等性キー（イベントID）で処理済みチェック if ($this->processedEvents->exists($event->eventId)) { return; // 既に処理済み → スキップ } $this->mailService->sendWelcomeMail($event); $this->processedEvents->markAsProcessed($event->eventId); } 同じ処理を何度実行しても結果が変わらない (冪等性) 39/44
40. 課題3: メッセージ順序の乱れ 非同期でも時間的結合が残り、順序に 左右されてしまうケース。 メッセージが独立していても、 「A が終わったら B」という依存が あれば結合する Vlad Khononov　著、増田 亨、綿引 琢磨　訳 ドメイン駆動設計をはじめよう 40/44
41. 解決: 通知パターンで 時間的結合を解消 推奨: イベント通知 広告最適化の完了をイベントにする ことで、メッセージの方向を変える Vlad Khononov　著、増田 亨、綿引 琢磨　訳 ドメイン駆動設計をはじめよう 41/44
42. 非同期処理での注意点と解決パターン 課題 具体例 解決パターン 整合性のズレ DBは保存できたのに メッセージが送れない Transactional Outbox 同一トランザクションで保存 重複実行 再送でメールが2通届く 冪等性キー 処理済みチェックで重複スキップ 順序の乱れ 有効化メールが ウェルカムメールより先に届く 順序非依存の設計 その他にも、メッセージ発行後に元の処理を取り消したい場合などは、 補償トランザクションなどが必要になる。サービスによっては、サポートしてる機能が あるので、そちらも利用する 42/44
43. まとめ 時間的結合は、メインフローが外部 API や重い処理の完了を待つ依存関係 メッセージング: キューに積んで先に返す 自分のコードベースで時間的結合が起きている箇所を探す 「この処理は本当に同期でなければならないか？」 参考: ソフトウェア設計の結合バランス ドメイン駆動設計をはじめよう 43/44