0

We are writing a C# application to process events/ messages from a student application system. The web based portal sends events/ messages to a queue table. We dequeue these and, based on message type, want to process each event.

Example events are ‘applicationSubmitted’, ‘applicationUpdated’, ‘offerAccepted’ etc.

There are quite a number of different event/ message types. We want to use the CQRS pattern, but would value input on how commands would be structured. Would you create a command for each event/ message type? Would you use a command factory of some sort?

Rich W
  • 85
  • 1
  • 5
  • 1
    Events can have zero to many receivers. There is no one to one relationship between events and commands. How you create and structure your commands will depend on what you want to do when each event happens. For some events you will do nothing, for others you might do many things. If you want an answer, you'll need to explain what scenario you want to solve, what question you have for that scenario and ideally what options you have already considered – Francesc Castells Oct 20 '22 at 22:11

1 Answers1

0

In an event-driven CQRS architecture, the events are the result of validating commands (commands can be rejected, events can be at most ignored (but cannot be denied)). Typically you have commands coming into an application which validates them against a write-model (almost always with some sort of concurrency control which imposes an ordering), which is the authoritative source of truth emitting events for consumption by a read model.

So the question then becomes, where is your write-model?

You have a web-based portal sending events/messages to a queue. Is that portal the authoritative source of truth? If so, then it's writing events to the queue and your commands sound like they're going to be the HTTP requests and their bodies: you can structure those like you would any other web request.

On the other hand, if the processor which dequeues the message is maintaining its state and deciding what the truth is, then "application submitted" isn't an event but is a command (in which case, a more imperative phrasing is probably less confusing: "submit application").

Very often, one finds that one component's events are another component's commands.

The command pattern doesn't really have anything to do with the C in CQRS. The latter "command" is in the (to use the domain-driven-design terminology) architecture bounded context and the former "command" is in the lower-level implementation bounded context. Neither implies the other. Similarly there's a (perhaps small) distinction between "event" in the architecture bounded context (along the lines of event-driven architecture) and "event" in the implementation bounded context (along the lines of event-sourcing).

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30