I’m not an expert on CQRS, so correct me if I misrepresent it.
Temporal is not a technology to implement CQRS. It is a technology that can be used instead of it for a large number of use cases.
My understanding that the main reason for using CQRS is a desire to build an event based architecture. But it comes with many drawbacks. Mostly around eventual consistency and being a pretty low-level abstraction for developers to deal with directly. CQRS by itself is just a pattern. It still requires choosing particular implementations of event storage, durable timers, and associated client-side libraries.
Temporal is fully event-based and asynchronous. It is an architectural style, programming model, and concrete production-ready implementation. Temporal abstracts out most of the complexity of building and operating resilient processes from short to never-ending ones. Internally Temporal uses event sourcing for recovering program state, but it is more like implementation detail that does not affect directly how applications are designed and written.
I can see Temporal being great for the Write Side (Domain Model) but I can’t understand how the Read Side (View Models) may work.
In Temporal a unit of computation is called Workflow. The workflow can contain a very complex domain model. Workflow has its own threads to drive activity executions and it can react to asynchronous external events. It supports read operations to its state directly through a sychronous query feature. Temporal workflow is fully consistent. So it doesn’t have a problem that CQRS has with eventual consistency of view models.
Temporal allows creating service oriented architectures that consist of workflows and activities that are hosted by different services and invoke each other. You can think of Temporal as a service mesh that supports operations of unlimited duration.