Self-resetting circular flow in wolkenkit - wolkenkit

Question

I have a question about stateful flows, I'll try to break it down to a really simple example:
I am using different states, lets say pristine, add, and calculate.
My state consists of an int that I want to add to, and after I added to it twice, I want to calculate the doubled amount, then set it to pristine again.
So now I'll start off with a pristine flow, int = 0. Inside my transitions I react to a addNumber event, take an int out of the event data and add it to my state, then I transitionTo('add').
I repeat this, add another number and transitionTo('calculate').
Inside my reactions I now react to the transition between add and calculating and set the new State to double the amount of the int.
What i want to do now is work with that number, for example send a command containing it, and then reset the state and transitionTo('pristine').
The problem is: I can't set the state neither can I transition.
How do you tackle this?
Here you have the actual code so that it becomes a bit more understandable:
'use strict';
const identity = {
'usermgmt.user.presentSwitched': event => event.user.id,
'usermgmt.user.pauseSwitched': event => event.user.id
};
const initialState = {
is: 'pristine',
present: false,
pause: false,
presentSince: null,
presentUntil: null,
pauses: [],
};
const transitions = {
pristine: {
'usermgmt.user.presentSwitched' (flow, event) {
flow.setState({
present: true,
presentSince: event.data.timestamp
});
flow.transitionTo('present');
}
},
present: {
'usermgmt.user.presentSwitched' (flow, event) {
flow.setState({
present: false,
presentUntil: event.data.timestamp
});
flow.transitionTo('calculating');
},
'usermgmt.user.pauseSwitched' (flow, event) {
const newPause = {pauseSince: event.data.timestamp};
flow.setState({
pause: true,
pauses: [...flow.state.pauses, newPause]
});
flow.transitionTo('pause');
}
},
pause: {
'usermgmt.user.pauseSwitched' (flow, event) {
const pauses = Object.create(flow.state.pauses);
pauses[flow.state.pauses.length - 1].pauseUntil = event.data.timestamp;
flow.setState({
pause: false,
pauseSince: event.data.timestamp,
pauses
});
flow.transitionTo('present');
}
}
};
const reactions = {
present: {
'calculating' (flow, event, services) {
const {app, logger} = services;
const workDayId = 'kek';
const from = flow.state.presentSince;
const to = flow.state.presentUntil;
const pauses = flow.state.pauses;
logger.info(JSON.stringify(flow));
app.keksing.recording().createRecording({workDayId, from, to, type: 'working'});
flow.setState({
present: false,
pause: false,
presentSince: null,
presentUntil: null,
pauses: [],
});
flow.transitionTo('pristine');
}
}
};
module.exports = { identity, initialState, transitions, reactions };
https://gist.github.com/DrFelder/122a72ffed3eb239a1a3ae33c99ea00d

Answer 1

Basically, there are two thoughts on this:
The first option is to question whether you should use a flow at all here. Maybe you could model this as an aggregate, with commands such as startWork, endWork, pause and resume, with the desired state, and then you could have the logic you want to have inside of that aggregate. You could either use a single aggregate per person, or a single aggregate per presence block. Either way, this should work. So, to put this in different words: Is there a special reason why you want to implement this as a flow, and not as an aggregate?
The second option is not to differ between pristine and calculating. Because, what you effectively want to have is some kind of a circle, but your flow isn't modelled as a circle. So if instead of finally transitioning to calculating you transitioned back to pristine, you would be in the desired state, and inside of the reaction of present->pristine, you could do the calculation you want to and send a command with the calculated data (which, actually, is the reaction to the transition).
Does this help to clarify things a little bit?
PS: Maybe it would also help to be more explicit in naming, e.g. to have paused and resumed instead of pauseSwitched. This would require less logic to figure out the intent of what has happened, and that's basically one of the strengths of DDD, to have the ability to be explicit in wording. Because, as it is named right now, it is more some kind of an updated event (which should be avoided).