2

I'm new to saga.

Here a simple scenario :

  1. User click "Create Order" : an order is created (holding its state = NEW at first)
  2. Once the user has finished filling the order, click SAVE --> state is now SUBMITTED
  3. When another check the order and VALIDATE it, then a process must occur. The order is VALIDATED only if some others services are called and give their GO.

The whole workflow is :

  • NEW-> SUBMITTED.
  • From SUBMITTED the user can cancel is submission and the order switch back to NEW.
  • The validation can either set the Order status to VALIDATED or REJECTED.
  • If REJECTED the orginal user must fix his order before put it to VALIDATION again.

So I need to avoid that the order can rollback to NEW when a VALIDATION is in progress.

My question is, for step 3, is it better to :

  • update the state of the order to PENDING, raise an event and start a saga (with its own state and the orchestration of the process and the routine slip) ?
  • remove the state from the order aggregate and put it into the saga (so the saga starts at step 1) ? the saga is named OrderSaga and encapsulates all the process from start to finish and not only the parts where external services are needed, i.e distributed transaction).
  • something else ? (links to blog or google group mail appreciated)

thanks

Archange
  • 397
  • 5
  • 21

1 Answers1

2

DDD is about the domain so first you need understand the business needs. So, let's see what are the rules:

  1. A new order can be created
  2. A created order can be submited but after it is validated
  3. The validation process could take some time and it can be canceled. If it is canceled the order can be submited again
  4. The validation process could either reject the order or accept the order
  5. If the order is rejected it can be submitted again after is corrected
  6. If the order is accepted it is sent to the next process and it cannot be submitted or corrected.

That being said, I would keep separate the two processes (the order creation+creation and the order validation). Also I would keep a status property on the OrderAggregate that is being used to enforce its invariants. The status can be:

  1. new: after the order is created or the validation is canceled or order is rejected
  2. submitted: after it is submitted for validation
  3. sent: after it is accepted by the validation process.

You should add new states only if you need aditional behavior.

The OrderValidationSaga would also have an internal status used to keep track of the external responses received from the external services. Let's suppose that we need to use two external services. The status would be an object with two properties: service1IsOk and service2IsOk. When any of the services says that the order is invalid then the saga rejects the order regardless of the internal progress and it resets its internal state. When a service says OK then the saga mark it internally as OK then it checks if all the services are OK. If they are OK it tells the aggregate to send the order. Then the aggregate marks the order as sent and emits an event. If/when the process is canceled, the saga resets its internal state.

Note that if you use CQRS then all the status changing are done by sending commands and raising events. The saga would subscribe to events and send the appropriate commands to the aggregate.

There is a fine article here.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • Do you also change the OrderAggregateStatus when the OrderValidationSaga is started (to `VALIDATION_PENDING`) ? If not how do you handle that the submission can be **cancelled** because the last internal status is `SUBMITTED` but a saga is going on (and can last a few hours). Or do you also check the internal status + if a saga exists (seems more complicated to me). ? – Archange Apr 22 '17 at 08:26
  • @Archange From what I understand before the validation starts it has the `submited` status. `Submited` is equivalent to `validation in progress`. Then it can be `canceled` or `validated` (aka `sent`). Keep in mind that you store in the aggregate whatever status or anything that you need in order to decide what to do/permit next. – Constantin Galbenu Apr 22 '17 at 08:39
  • Ok I updated my question. The workflow is : `NEW` -> `SUBMITTED`. From `SUBMITTED` the user can cancel is submission and the order switch back to `NEW`. The validation can either set the Order status to `VALIDATED` or `REJECTED`. If `REJECTED` the orginal user must fix his order before put it to VALIDATION again. So I need to avoid that the order can rollback to `NEW` when a `VALIDATION` is in progress. – Archange Apr 22 '17 at 11:00
  • @Archange, so it seems that you figured it out. Do you need somethong else? – Constantin Galbenu Apr 22 '17 at 11:17
  • Do you think that introducing a `Validation_in_progress` status is a solution ? or do you prefer to check if a ValidationSaga aggregate exists ? – Archange Apr 22 '17 at 11:31
  • `Validation_in_progress` status seems like the way to go. Keep in mind that the saga is not a real aggregate, it does not emit events. It listen to `SUBMITED`event, it calls the external services, it updates its internal state and when the process is complete it sends a command to the aggregate to `send` it (or whatever the next step is). – Constantin Galbenu Apr 22 '17 at 11:50
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/142343/discussion-between-archange-and-constantin-galbenu). – Archange Apr 22 '17 at 14:32