To commanded or not to?

That’s a great question.

There are several things I think that will help you decide

  1. Event Sourcing and operations history for analytics are very different approaches, though they might seem similar. Event Sourcing pattern works only when you store the command/event in casually ordered chain before you actually apply this operation to read or write model. This approach makes sure that the

    1. Each event and command has happened in exactly the same order as it is stored in Event Store. This is extremely useful for any money-related problem or for distributed transactions with very critical data
    2. It is easy to rollback in time and replay some events from exact time to find a bug or inconsistency or security breach or whatever

    On the other hand, analytics are not required to have casual or linear order. Most of analytical data can be stored after the request was processed. Analytical data can be lost, since it is not critical and data loss just decreases quality of the analytics. Most of the analytical data can be aggregated. Analytical storages do not need to have ACID and append-only properties (which are required for Event Stores), and they can be column oriented like Clickhouse.

  2. Commanded linearizes all events and commands in a single process and then stores them in the Event Store. This is clearly a bottleneck for heavily loaded systems, but it is very useful for systems where linear order of commands/events is required.

Given the two points above, you don’t need Event Sourcing and therefore you don’t need Commanded.

I’d recommend time series or OLAP databases such as Clickhouse. This choice depends on the kinds of analytics you want to gather.