space-cqrsbut you don't have to expose your whole app
Can you elaborate on "but you don't have to expose your whole app” ?
What about a new space package, space-queue that sets up the job-collection, which the snapshotter, scheduler, and cache rebuilder all use? space-workers are isolated in their own package would observe the queue and complete jobs when they are triggered via observers on the job-collection.
Or an infrastrucure package (space-infrastructure) with classes queue, worker, scheduler, snapshotter, rebuilder ? That would be more flexible, and allow for configured background apps to achieve specific goals
class SnapshotSportingEvent extends Space.infrastructure.snapshotter schedule: ‘every day at 0300’ maxEvents: 100 eventStream: ‘SportingEvent'
class Space.infrastructure.snapshotter extends Space.messaging.controller Dependencies: queue: 'Space.infrastructure.queue'
Hey @rhyslbw sorry for the absence, I was away from the laptop for the last 3 days ;-) I will travel to Barcelona today, so unfortunately there is not much time either – tomorrow could be a good time!
To answer your question: Yes, there are many different implementations floating around the DDD + CQRS community. I chose an approach where Sagas/Process Managers are also just event-sourced Aggregates with one additional capability: sending commands to orchestrate other parts of the system. So in
space-cqrs process managers are also just domain-level objects that have no idea about the infrastructure (message routing, persistence etc.). I also realized that this has drawbacks in some situations. For example, you need extra events to persist the state of the process manager which sometimes have ugly names like
CustomerRegistrationEmailRequested. At the same time I like the concept that processes are first-class domain concepts.
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