在设计应用程序的后端时，您通常需要从实际执行任务的系统中抽象出执行这些任务的系统。
在CQRS和PubSub设计模式中有这样的元素。
举个例子：
- 新用户提交注册表格
- 您的应用程序接收到该数据并推送一条消息，上面写着
“hey i have some new user data, please do something with this” - 侦听器/处理程序/服务获取数据并进行处理
（如果这没有意义，请告诉我）
在我的申请中，我通常会：
- 激发侦听器设置为处理
Event::fire('user.new', $data)的新事件 - 使用数据创建一个新命令，该命令绑定到CommandHandler
new NewUserCommand($data) - 调用Service中的方法并传入数据
UserService::newUser($data)
虽然这些几乎完全相同，但我只是想知道，在创建应用程序的体系结构时，如何决定使用哪一个？
激发侦听器设置为处理的新事件事件：：fire（'user.new'，$data）
事件模式意味着可能有许多处理程序订阅同一事件，而这些处理程序与发送方断开连接。此外，事件处理程序通常不会向发送方返回信息（因为实际上可能有许多处理程序，并且对于返回谁的信息存在混淆）。
所以，这不是你的情况。
使用绑定到CommandHandler的数据创建新命令新的NewUserCommand（$data）
命令是执行某些操作的扩展方式。它们可以被调度、流水线、排队等等。如果你不需要所有这些功能，为什么要把事情复杂化？
调用服务中的方法并传入数据UserService:：newUser（$data）
这是最适合你的案子的，不是吗？
虽然这些几乎完全相同，但我我只是想知道——你怎么决定什么时候用哪一个您正在创建应用程序的体系结构？
简单。从许多解决方案中只选择以下解决方案：
- 比喻上合适（不要使用事件，因为您的逻辑看起来不像事件）
- 最简单的（不要过于深入编程理论和方法的深度。总是选择解决方案，这样可以降低项目开发的复杂性）
何时使用命令控制事件？
命令：当我有一些单个孤立的操作，并且几乎没有依赖项时，必须从不同的应用程序部分调用这些操作。最类似的是一些编辑器命令，它可以从工具栏和菜单中访问。
事件：当我有几个（至少在透视图中）依赖操作时，这些操作可能在执行其他操作之前/之后调用。例如，如果您有多个服务，则可以使用事件为它们执行缓存无效。更改特定对象的服务会发出"IChangedObject"事件。其他服务订阅此类事件并对其作出响应，从而使其缓存失效。