> commands and events are both events are both messages*
On Friday, September 14, 2018 at 9:35:10 AM UTC+3, Daniel Plainview wrote: > > > In practice, the Message is essentially a command bus. > > This is kinda inaccurate language when you say that "message" is a "bus"... > But more importantly, message can be either command or event: why do you > make accent on "command" bus? > Command bus MAY return something (it doesn't violate CQRS: > https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/; CQRS is > about write and read models [look at the definition]; it's a widespread > fallacy that CQRS says something about what method should return or not) > from the command handler; on other hand, event bus is not able to do this. > > I suggest to do not use abstract "message" word: commands and events are > both events, but they can be handle way differently. > > On Thursday, August 30, 2018 at 11:49:03 PM UTC+3, Larry Garfield wrote: >> >> We had another energetic call today. At this point we're arguing about >> minutia and details, which I take as a good sign. Highlights include: >> >> * We're going to rename StoppableTaskInterface::isStopped() to >> isPropagationStopped(), since that's what both Symfony and Zend Framework >> call >> it now. >> >> * Cees-Jan showed a React Promises-based proof of concept. By and large >> it >> looks like the spec is compatible with that workflow as is with no need >> for >> further revision. See: https://github.com/WyriHaximus/php-broadcast >> >> * We discussed performance considerations, especially prompted from >> discussion >> with the Doctrine team who have concerns about event handling at extreme >> scale. Larry has added benchmarks to his implementation that suggest >> performance should be more than fine. We will continue to monitor the >> performance question though and make sure there's no unexpected gotchas. >> >> * We spent quite a bit of time discussing the fate of the Message vs Task >> use >> cases. In practice, the Message is essentially a command bus. Task is >> what >> nearly all PHP libraries today call Events, even if that is academically >> inaccurate. We're OK with that, and I'll be adding more clarity on that >> to >> the spec or metadoc. While they overlap considerably, they also do have >> different use cases. Are they enough that we should split the spec in >> two? >> Or that we should keep a unified spec but split up the packages? We're >> not >> sure, and we want to get input from others. (That means you, reading >> this, we >> want your input!) >> >> **PLEASE TAKE A MOMENT FOR THE BRIEF ASK BELOW** >> >> I've put together a very quick survey we'd like to have people respond to >> to >> help gather input on that point. This is *not a vote*, it's a >> non-binding >> survey for feedback. We actively want feedback from everyone, whether >> you're >> a "formal" member of FIG or not. Please take 30 seconds to respond to >> the >> following survey within the next week or so. >> >> >> https://docs.google.com/forms/d/1fvhYUH6xvPgJ1UW9I-3pMGPUtxkt5_Ph6_x_3qXHIuM/ >> >> viewform >> >> --Larry Garfield >> PSR-14 Editor >> > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f724a8e6-1fe2-4336-a11a-e48a4cbe9b69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
