4

I have a CQRS .NET Core service that currently has a single endpoint for each command. Sometimes a collection of commands makes up a single action in the system (e.g. create an assessment) and 3 or so commands have to be executed synchronously once the previous command has commited data to the db (this is because of the legacy database design).

At the moment this is handled by the client where each command fires after the it's previous dependent one has completed (using promises).

It's worth noting that these commands are also executed individually at times and if they were combined in to a single command it would end up being massive and very hard to test.

What I want to do is create a single endpoint that manages operations like our create assessment one, which has to execute the following commands one after the other:

  1. UserCreated
  2. AssessmentCreated
  3. AssessmentRegisteredToClient

I've have been going down the route of using a MassTransit saga/state machine/process manager but the more I work on it (and the more my understanding improves) the more I think it seems like overkill and not the right approach (as these are commands and not events and all within a single bounded context).

Does a process manager seem like the right fit and if so is the MassTransit state machine implementation the way to go or should I look at other sources? Or should I just simply create an endpoint that fires each command one at a time (i.e. have this synchronous code in the ASP controller)?

Ben Thomson
  • 1,083
  • 13
  • 29

2 Answers2

9

Just to clarify, UserCreated is not a command, it is an event.

You have three choices here:

  • Build a reactive system instead. So, after CreateUser (btw, not a very good language here since you never create your users, they register in your system) you emit UserCreated, which causes a reaction that sends a command CreateAssessment and so on.
  • Use MT saga as a process manager. State machines are very well suited if you need to ensure that your somewhat complex workflow completes (or fails) in a way you expect.
  • Use MT courier feature to implement a distributed transaction. You will have a sequence of activities, actions and compensating actions (reversals).

I would personally analyse my problem to find out what is the bare minimum I need to do before I can return to the user and say "it's ok". The rest can be done asynchronously, behind the scenes. It is more to the domain analysis than for the tech.

Update 04/12/2019, answering one of the comments:

Again, there's an issue with the terminology that is currently applied. Many messaging libraries, like MassTransit, Rebus or NServiceBus use the word saga for process managers.

Using the original terminology, process managers handle the whole process with possible deviations and parallelisations. Sagas, on the other hand, implement a single-flow process. When any step in the saga fails, everything that happened before gets reverted using compensating actions. There's no orchestration for sagas as each step is independent and when one step is complete, the next step gets executed. Sagas are always stateless and if there's a need to include some additional information for the next step, the saga activity needs to put it to the payload.

A process manager is, by definition, the orchestrator. It never does the work themselves, but instruct other components to do the job. Then, by listening to events, the process manager decides how the process should flow. The process manager can initiate a compensation action, but it doesn't perform the action itself, it instruct another component to do the job. For the purpose of keeping the current state of the process, process managers are stateful.

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
  • Why would consider UserCreated to be an event and not a command (or not both)? It is my understanding that because a user record is being created in the database (in this case an anonymous one) it is a command? I think this is where my understanding starts to get a bit rocky. And unfortunately the bare minimum is all three "commands" completing and none of them can fire asynchronously as each requires that an entity from the previous is committed in the database. What I'm struggling with is how t o actually do this using an MT saga but I think I can work it out. – Ben Thomson Mar 26 '18 at 23:41
  • Where I'm struggling with this though is how to "start" my saga and structure it. Do I listen for a UserCreated event (which is fired after the user is created) or is there a better way like sending a new command (e.g. something like CreateAssessmentAndUser) and then going going from there? – Ben Thomson Mar 27 '18 at 00:03
  • 2
    Distinction between commands vs events is very clear. Commands express the intent to do something, events convey the fact that something has happened. The imperative style of commands means that the sender tells the receiver to do something. But it is not done yet. Command handling can fail and there will be no event produced in this case. This distinction is important. – Alexey Zimarev Mar 27 '18 at 07:46
  • Concerning the structure - it is again less technical and more to the design. Usually sagas only listen to events and coordinate the follow up actions. So yes, starting it by UserCreated would be preferable. – Alexey Zimarev Mar 27 '18 at 07:48
  • This is all really helpful. Thank you everyone. – Ben Thomson Mar 27 '18 at 12:19
  • @AlexeyZimarev Is compensating actions what makes saga different from process managers? – adnanmuttaleb Dec 04 '19 at 08:00
  • 1
    @adnanmuttaleb updated the answer. it wasn't fitting to the comment. – Alexey Zimarev Dec 04 '19 at 11:26
1

Because all commands are processed by the same Aggregate, a solution is to create a 4th combo command, named from the Ubiquitous language, that contains the 3 commands. Internally, the Aggregate just calls the 3 command methods, thus no code duplication.

Along being the simplest solution, it is also made explicit that, in this particular use case, these commands are executed in a single transaction and in that order: they all succeed or they all fail.

P.S. as @AlexeyZimarev pointed out, those are not commands but events

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • Thanks. I might go down this path as it's definitely the one of least resistance. And do you say they're all events because of the tense that has been used e.g. AssessmentCreated as opposed to CreateAssessment? – Ben Thomson Mar 27 '18 at 04:52
  • @BenThomson they are events because they express facts that already happened. On the other way, the commands express the *intent*, the *wish* to do something that may not happen. – Constantin Galbenu Mar 27 '18 at 05:01
  • @BenThomson you should question every thing and everyone :) – Constantin Galbenu Mar 27 '18 at 05:14