Distributed Decide-Act-Report Model

Yesterday I gave a talk on CQRS with Windows Azure at Copenhagen GOTO Conference (slides, PDF).

Mark Seemann (who was the very reason of me coming to Copenhagen) provided invaluable feedback on the talk. He really liked the analogy for explaining relations between commands, events and views in the cloud architectures. So let's go over it in this blog post.

Let's think, how some real-world organizations might function like. With some imagination you can identify 3 roles:

Managers, that run organization; they read paper reports or call assistants, decide and issue orders for the workers below them to execute.
Workers, that receive orders, act upon them (where they can and have the resources) and notify various departments about the job done.
Assistants, that gather together all these notifications, mails and memos into various reports, making them available to anybody, who has to make the decision.

Obviously, the entire iterative process of decide-act-report takes some time. It is not instantaneous, because humans are slow. However, this somehow seems to works in the real world. Companies seem to make right decisions that guide them through the ever-changing business world. They even manage to grow into large organizations (with more complex structures).

In short, this structure - works. Now, take a look at the image below.

Does this "Decide-Act-Report" resemble a bit the classical distributed architecture implemented with CQRS in mind?

In this world, users are the managers, who decide, what to do in the UI. They use the latest reports available to them in form of Views (aka Read Models or Projections) in a way, that makes it simple to make a decision. User interface captures their intent in the form of command messages, that order server to do some job.

Servers, then, work hard to do the job, acting upon the commands messages sent to them. Upon the completion (or any other outcome), notifications are sent to all interested parties in form of events messages published via pub/sub.

View event handlers (Projection Hosts) receive these notifications, building Views to report their data to the user. They work even harder to keep these up-to-date, updating them upon every event message. Since these reports are kept up-to-date, any interested party can query and an immediate result, without the need to wait for the report to be computed.

Everything is rather straightforward, as you can see. At the same time, some of the analogies from the real world can still apply. For example:

There could be multiple managers, operating the same organization at the same time == multiple users can work concurrently with an application.
If there is too much work, you can hire some more workers == if there are too many commands, you can add more servers.
Actual reports can be copied and distributed around the organization, JIC if manager needs them right now == you can spread read models around the globe to keep them close to the client (or even keep them at the client).
Manager, workers and reporting assistants could be in the same building or they could be spread across the continents, while exchanging mail between each other == distributed application with messaging can have all components as in a single process or it can spread them across the data centers.

So, again:

User - looks at views, decides and issues commands
Command Handlers - receive commands, act upon them and publish notifications
View Handlers - receive interesting notifications and update views, immediately reporting them to the interested parties per request.

Does this analogy make things a little bit simpler in the distributed CQRS world with users, command handlers and event handlers?

Published: May 12, 2011.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out