Processbecause manager is pretty generic anyway
So based on the discussion we had relating to the Space.cqrs.ProcessManager and some more research I’m in favour of reworking it based on the State Machine pattern. Here’s a good excerpt from the MS Journey project:
"In this bounded context, a process manager is a class that coordinates the behavior of the aggregates in the domain. A process manager subscribes to the events that the aggregates raise, and then follow a simple set of rules to determine which command or commands to send. The process manager does not contain any business logic; it simply contains logic to determine the next command to send. The process manager is implemented as a state machine, so when it responds to an event, it can change its internal state in addition to sending a new command.
Our process manager is an implementation of the Process Manager pattern defined on pages 312 to 321 of the book by Gregor Hohpe and Bobby Woolf, entitled Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Professional, 2003). “
Have you read these articles? Given the state machine pattern still needs to record a log, maybe it is better to retain event sourcing as the persistence, but instead of just extending the aggregate, the event sourcing functionality be extracted that can then be extended by the Aggregate class and the Process Manager class
Hey @withinboredom. No but the latest space:messaging includes a basic custom queue using Mongo. It’s undocumented right now but check this commit for changes and tests CodeAdventure/space-messaging@aa286c7
It’s brand new and I’ll be starting an implementation using it later today
The project @DominikGuzei and I are working on uses meteor apps and a node microservice too. The meteor-space apps are inpendant but have integration points, which is why we feel it would be a natural fit for space-messaging to provide a lightweight distributed solution.
We’re using https://github.com/vsivsi/meteor-job-collection as it’s much more powerful and is built to suit to exact purpose of running node workers. I did look at meteor-workers when doing reasearch a while back, but I heard Ry Walker of Differential discuss the project on a podcast, and he mentioned it was practically abandoned. Job Collection on the other hand is one of the most solid projects on the other hand, being actively developed, well maintained documentation, a comprehensive test suite, and support from the author.