Hello @solnic . I am prototyping EventSourcing toolkit with parts of dry-rb ecosystem. And sure I could not resist taking a look at dry-event. Would you kindly share your vision and rationale behind it?
I've copied usage of Dry::Equalizer right away :) But usage of constructor method is somewhat puzzling. As I am looking for way to use dry-types for description of event objects, looks like you driving in different direction.
And listener_method as a part of event itself is another interesting choice.
@andriytyurnikov dry-event is actually something I extracted from rom-core, so that I can re-use it in dry-monitor. rom 5.0 will use it too. Its API is not stable, so things may change. I don't have any specific vision, just needed a simple pub/sub lib that's easily reusable and fits within dry-rb philosophy.
BTW I'm interested in EventSourcing and plan to do some work on it later this year. Like resurrecting rom-event_store and building some nice abstractions on top of it
@solnic just when I'll have something with minimal real world value - I'll gladly share my prototypes to illustrate my understanding of the problem. Right now dry-rb ecosystem seems very attractive as a provider of reasonably good primitives. Ability to cross-combine seems important for good primitives. I try to rely on dry-types and hash schemas as flexible validation and interface contract enforcing layer. Basically I just wanted to pre-sell you an idea that Event primitive might be very important in many different cases, and having it being compatible with dry-types may give additional benefits for your case ... and beyond :)