Skip to content

CQRS Process flows

Sam edited this page Jun 25, 2017 · 12 revisions

Process Flows

The first step in working with the CQRS.NET is understanding the ideal work/process flow, that is, how a request should flow a CQRS system; what steps, modules and class a request should travel through from start to end.

E.D.A. via S.O.A.

This article will discuss the idea of having a micro service based event driven architecture driving a service orientated architecture A.P.I... or end-point for a domain. This means that requests to the domain to modify state are asynchronous. At a high level, you start by making a request for state to be changed, receive a token for that request, and then await a response, or several responses, with a matching token.

Diagram

Process flow

Step 1 - A.P.I. - Call made

Step 2 - A.P.I. - Request authorised

Step 3 - A.P.I. - Create service request

Step 4 - A.P.I. - Send service request to service layer

Maybe via WCF.

Step 5 - Service Layer - Create new command

Step 6 - Service Layer - Publish command

  • Send the command to the command bus.

Step 7 - Domain - Create command handler

  • The command is received from the command bus.
  • The corresponding command handler (only one can exist) is instantiated to handle the command.
  • The command is passed into the command handler for processing.

Step 8 - Domain - Validate command

  • The command is validated to make sure it adheres to basic requirements such as required fields are provided, strings match certain criteria, such as being an email address. Further details are available.

Step 9 - Domain - Create aggregate

  • An instance of an aggregate is created and instantiated.

Step 10 - Domain - Rehydrate aggregate

  • If the command is intended to change the state of an instance of an existing aggregate, the aggregate is rehydrated.

Step 11 - Domain - Apply command

  • The command is applied. Business logic and rules are evaluated, state is not changed. Further details are available.

Step 11.1 - Domain - Create new event

  • Depending on the work flow taken based on your business logic and the commands values, one or more events are created.

Step 12 - Domain - Publish event

  • Send the event to the event bus.

Step 12.1 - Domain - Apply event to aggregate

  • The event is applied to the aggregate, here the state if the aggregate is finally updated.

Step 13 - Domain - Create event handler(s)

  • The event is received from the event bus.
  • The corresponding event handler(s) are instantiated to handle the event.
  • The event is passed into each event handler for processing.

Step 14 - Domain - Apply event

  • Such as updating a projection.

Step 14.1 - Domain Edge - Republish event to an external system

  • Such as publishing to front-end client via web-sockets.
Clone this wiki locally