Create, modify, or debug business events and their follow-up reactions, including order cancellation events, queued listeners, transaction timing, and rollback behavior.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Put business facts under App\Domain\<Capability>\Events and name them in the past tense, such as OrderCancelled. Do not create domain events for implementation details.
Domain may produce or record events; Application coordinates their dispatch. A direct dispatch call in an Action is a simple option, not the only permitted production mechanism. Do not require an event collector or aggregate base class.
Events carry facts and do not execute side effects or contain presentation logic. Prefer immutable scalar IDs or snapshots when a reaction needs the fact as it happened; a reloaded Eloquent model can reflect later state.
External reactions must happen after commit. For an event whose reactions should all wait, use Laravel's ShouldDispatchAfterCommit:
namespace App\Domain\Orders\Events;
use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;
final readonly class OrderCancelled implements ShouldDispatchAfterCommit
{
public function __construct(public int $orderId) {}
}
Application can call event(new OrderCancelled($order->id)) after saving, inside its transaction. Laravel defers this event until commit and discards it on rollback; without a transaction it dispatches immediately.
If an existing event must dispatch earlier, defer the external listener/job using the installed Laravel version's after-commit mechanism instead. Work required for atomic success should be explicit in the Action's transaction rather than hidden in follow-up listeners.
Keep listeners in Laravel's usual location. They delegate meaningful application behavior to Actions; a small technical side effect may stay in the listener. Prefer this event path for asynchronous follow-up work. Account for retries and duplicate delivery when the reaction changes an external system; after-commit dispatch alone does not guarantee delivery or exactly-once execution.
See order cancellation for the connected dispatch example. Test successful commit and rollback separately; an event fake alone does not verify real listener timing.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Create, modify, or refactor application use cases into Laravel-native DDD Actions. Use for business operations such as placing or cancelling orders, extracting controller orchestration, and fixing use-case behavior.
日本語の概要は準備中です。原文の説明を表示しています。
Create or change structured input for application use cases, including extracting HTTP request data for Actions invoked from controllers, jobs, or commands. Avoid DTOs for trivial scalar input.
日本語の概要は準備中です。原文の説明を表示しています。
Create, extend, or fix Eloquent business models and their state transitions. Use when moving business rules out of controllers or Actions, or explicitly migrating a model into a DDD capability.
日本語の概要は準備中です。原文の説明を表示しています。
Create or refactor business calculations and rules spanning multiple domain objects when no single entity or value object naturally owns the behavior. Use when assessing a growing service class.
日本語の概要は準備中です。原文の説明を表示しています。
Add, change, or debug external API integrations, vendor SDK adapters, and bridges to legacy business workflows. Use when an Action or domain service needs an outer technical dependency.
日本語の概要は準備中です。原文の説明を表示しています。
Create or change immutable business values with meaningful invariants, equality, or behavior, such as order numbers and money. Use when primitive values obscure domain rules; avoid wrapping every scalar.
日本語の概要は準備中です。原文の説明を表示しています。