Tutorial 2: Defining Business Logic Workflows

The single most important part of working with CS-CQRS is to understand what the business rules are that need to be executed.

For our example we have a rather basic UX workflow

There are various group orientated/collaborative ways to come up with business requirements. The purpose of this article isn't to get into the specifics of any particular approach such as Event Storming, we'll leave those discussions and research activities to you. What is important, is to identify that, to succeed your business needs to think from different perspectives. That is the purpose of this article.

For this step we are going to model the major requirement of the business... withdrawing money from an ATM, since that's the whole point of this system if it were the real world.

Withdraw Funds

Taking the above UX workflow, the business has identified the below business rules that must be followed.

Modelling in a different way

Taking the above business rules workflow diagram and making some adjustments, we can express the same business rules in an explicit way, removing any ambiguities and then identify the necessary aggregates.

With this diagram, we have the following improvements:

• Events and commands - the core components of CQRS
• Explicit responses stating error conditions, not "Raise an error"
• Aggregate boundaries showing context boundaries. If this concept is foreign or new to you, I suggest you read up on Domain Driven Design and the purpose of aggregates.
• Basic data validation - Amount > 0
• Business rules Amount < Account Balance. This is not validation as it requires knowing the state of the Account aggregate.
• We've also identified that we are crossing two aggregates and so we need an ability to do that. This is done via an event to command converter.

Here we've added a new event and command to allow two aggregates to be involved in the same workflow.

If we go one step further we can now apply some naming conventions and improve our DDD driven DSL. By having very explicit object names, if you were to print out and put all your workflow diagrams on a wall, you would never have two objects with the same name. Ambiguity removed.

This isn't a lot more work, but the advantage is that with details this explicit, code can be created for you by Visual Studio. What takes 5 minutes to add into a model can save 15 minutes of coding. In the next tutorial we'll show you how.

From here on we'll also skip the step-by-step, gradual improvement of the workflow diagrams and go straight from the UX workflow to the final business logic workflow with our DSL naming conventions applied.