[buffoon]

With respect to cross cutting concerns, your domain is fractured into something with temporal concerns i.e. events and a timeline. That doesn't reduce complexity, merely move it elsewhere and change the context to something unfamiliar. Then you have to remodel parts to enforce idempotency and handle command failures. Commands do fail but the caller isn't made immediately aware of this. Then there's the distribution and reliability concerns of the system which have to be absolute. If a complex event has numerous subscribers that all must complete, it is very difficult to provide guarantees of consistency even if it is eventual. So your logical isolation ends up with massive cross cutting concerns. For example your UI needs to be aware of the underlying model if the user requires confirmation that something has occurred. Also things like validation become terribly painful.

The cognitive load is the same as any distributed system. It adds massive complexity. If the surface of your application is a SaaS system it is far simpler to deploy hundreds of small tightly coupled instances than to scale it up to one massive instance architecturally.

[timclark]

I think a lot of what you are mentioning comes down to the implementation of CQRS / ES being used not fundamental flaws in the approach.

CQRS doesn't force you to build a distributed system. It doesn't make you use eventual consistency or asynchrony but provides them as options.

For example the system I worked on had synchronous command handling with a mixture of synchronous and asynchronous subscribers. This allowed us to use eventual consistency where it was appropriate and for all clients to be immediately aware of problems.