From Direct Calls to Event Signals: Modernizing PHP Architecture

Traditional Execution Model

In classic PHP applications, code follows a linear "execute signal" pattern where a controller directly invokes services and repositories, creating a tightly coupled command chain. A typical user‑registration method creates a user, sends a welcome email, updates analytics, and creates an initial space, all within the same function.

class UserController {
    public function register(Request $request) {
        // 1. 创建用户
        $user = $this->userService->createUser($request->all());
        // 2. 直接调用，发送欢迎邮件
        $this->emailService->sendWelcomeEmail($user);
        // 3. 直接调用，更新用户计数
        $this->analyticsService->updateUserCount();
        // 4. 直接调用，为用户创建初始空间
        $this->spaceService->createInitialSpace($user);
        return response()->json($user);
    }
}

Problems of this approach include:

Strong coupling between the controller and multiple services.

Violation of the Single Responsibility Principle, as the controller knows too much about downstream actions.

Poor extensibility; adding a new step (e.g., sending an SMS) requires modifying the existing method, breaking the Open/Closed principle.

Event‑Signal Model

Switching to a "emit signal" mindset turns the controller into a broadcaster that only signals that a user has been registered. Listeners elsewhere react to the UserRegistered event.

class UserController {
    public function register(Request $request) {
        $user = $this->userService->createUser($request->all());
        // 关键改变：不再执行具体任务，只是发出一个信号
        event(new UserRegistered($user));
        return response()->json($user);
    }
}

Listeners handle specific concerns:

// Listener A: send welcome email
class SendWelcomeEmailListener {
    public function handle(UserRegistered $event) {
        // 发送欢迎邮件给 $event->user
    }
}
// Listener B: update analytics
class UpdateUserCountListener {
    public function handle(UserRegistered $event) {
        // 更新统计信息
    }
}
// Listener C: create initial space
class CreateInitialSpaceListener {
    public function handle(UserRegistered $event) {
        // 为用户创建空间
    }
}

Benefits of the Signal Network

Extreme decoupling and high cohesion

Controllers no longer depend on concrete business logic; they only announce that registration occurred.

Each listener focuses on a single task, making the codebase clearer and more maintainable.

Unmatched extensibility Adding a new feature, such as sending a Slack notification, only requires creating a new SendSlackNotificationListener and registering it to the UserRegistered event, without touching existing controller code.

Improved testability Controllers can be tested by asserting that the event was dispatched, e.g.:

public function test_user_registration_dispatches_event() {
    Event::fake();
    $response = $this->post('/register', [...]);
    Event::assertDispatched(UserRegistered::class);
    // 测试控制器逻辑到此结束
}

Each listener can also be unit‑tested in isolation.

Asynchronous processing capability Listeners that implement ShouldQueue (e.g., processing a user avatar) are automatically queued, preventing long‑running tasks from blocking the HTTP response.

class ProcessUserAvatarListener implements ShouldQueue {
    // 这个监听器会自动被队列处理
    public function handle(UserRegistered $event) { ... }
}

Clear business workflow The event‑listener map makes the overall flow visible; inspecting the registered events instantly reveals what happens after a user registers, enhancing readability and maintainability.

Conclusion

Adopting an "emit signal, not execute" architecture transforms a monolithic command chain into a dynamic, loosely‑coupled network. Leveraging mature components such as Symfony's EventDispatcher or Laravel's Events enables PHP developers to build more elegant, scalable, and future‑proof systems.