Hi, I'm one of the core maintainers of the prooph project. We've defined a common Message interface https://github.com/prooph/common/blob/master/src/Messaging/Message.php that acts as the basic building block for all our packages. We tried to keep the interface as simple as possible. As you can see prooph messages support the architectural patterns CQRS and Event Sourcing (our main focus) by defining a message type and a message name.
Type is important because commands and queries should only have one handler/consumer whereby events can have many listeners (fanout). Message name is mainly used for routing and to describe the intent of the message (DDD / Event Sourcing). Our messages are *immutable* similar to what PSR-7 defines for Req / Res. Furthermore messages have: - a uuid (could be generalized to be only a string or we need a PSR for UUIDs ;) ) - metadata (custom key => value pairs) - payload (application data) - createdAt (a \DateTimeImmutable because it includes micro seconds) IMHO a messaging API PSR is too much but a *Message PSR* (like PSR-7 is) would be nice. Http req / res are very similar to other types of messages and in fact Zend promotes this for years: stdlib MessageInterface: https://github.com/zendframework/zend-stdlib/blob/master/src/MessageInterface.php http messages implement stdlib: https://github.com/zendframework/zend-http/blob/master/src/AbstractMessage.php We have PSR-7 (which is a good thing) but we have no general PSR for messages. If we would have such a PSR then libraries dealing with messaging could build their logic on top of it. For example prooph messaging system integrations rely on prooph's message interface. We have integrations for Bernard, amqp, ZeroMQ, AWS SQS (not open source) and HTTP for inter process communication and the same message interface is used to route messages within an application, let event sourced aggregates record domain events which are then stored in an event store and pulled by projections. All these use cases are supported by this "simple" interface and it did not change much over the last 4 years. I'm not saying it is a perfect foundation for a PSR (f.e. we rely on Ramsey\Uuid) but I think a message interface defined by a PSR should not be more complex than the prooph message interface. Everything else can be designed around it (like done with middleware PSR-15) Best regads, Alex -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bfe34052-1425-4096-8068-d4686998d37e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
