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