good day ! We are in the throes of a project that unfortunately is more R&D than implementation. I have a concept of a process manager service that has its own event stream and communicates with the services it manages by events appended to their own event streams.

below is what I posted to the DDD/CQRS google group: no discussion yet.


I have a process manager that "wakes up" at a certain time and polls a feed (more confusion on that later). NOW it has something to do with some stuff ....

Should this process manager service append a "Command Given (aka Request)" to a "downstream called service"s input stream OR should the "called service" subscribe to the event the process manager documents for itself OR to some sort of projection OR do I have my terminology all screwed up (likely).

NOTE: I expect that the "called service" would append a "Result Returned (aka Response)" to the upstream process manager service input stream OR the upstream process manager service would subscribe to the event the "called service" documents for itself OR do I have my terminology all screwed up (again most likely).

Help - I'm a domain expert stuck in a communication do loop with developers.

Hi,

Interesting scenario. From what I can tell I would probably have the downstream service poll the upstream service like we did in the REST example. I think there are few reasons why my initial reaction is to go this way:

1. the downstream service may want to do some processing of before events are added to its stream.

2. in future there may be other subscribers of the data. Having to update a service each time a new subscriber is added may cross team boundaries.

Does that sound reasonable? If you want to share more details I'd be happy to have another take.

Cheers

thanks for the reply. My view is that I'm describing a pattern, not any one process. I believe that the downstream is 'called' because the process manager needs its processing ..... ? Not sure why that would make one think differently about the pattern ... ? btw nick ... great book; like Eric's, the philosphical parts read well.

Hi,

Apologies if I was unclear. I was trying to suggest that the pattern and the implementation can be different. For example, in the REST examples, it's the publish-subscribe pattern. However, with the implementation, the subscriber actually polls for the events, whereas in other implementations the sender actually pushes the message onto all subscribers.

I wondered if the same might apply here but I was really just speculating without knowing the full details. I think either approach could work.

Cheers

I liked that comment in the book. And that is why I like the 'skeleton' of geteventstore, realizing it is not the only way; but can be used in different ways.

Can you comment on the following ?

Ways to conceptualize a geteventstore stream ..

data streams - are appended to and polled from
log streams - are projected from to support read models
service streams allow aggregates/process manager state to be event-sourced
also the mechanics of ges is message transport between services.

it is in the last one that my original question is about ...

regards,