Event sourcing without CQRS

CQRS is about separating the reads from the writes. Write operations need things like locking, guaranteed order, and always the latest state. In classical systems (relational databases) you would also give this guarantees to read operations, which comes with a huge performance impact and big issues when it comes to scalability. That's why in CQRS you give read operations a separate copy of the data which is optimized for fast reads, e.g. it is denormalized and put into more efficient, faster systems (e.g. a memory cache), I'd call this a "read view [on the system's data]".

CQRS works without ES, because you can create the optimized read view from a traditional data store (e.g. a relational database).

ES does work without CQRS, but only if the number of events is reasonably small. Because you are storing all the changes of the system in a database and every read has to use the same database and iterate over all events that it needs to fulfill the query. Eventually there will be too many events that need to be read in order to answer and the time it takes to answer will become too long.

Does event sourcing without CQRS make sense?

Yes, in the sense that CQRS and Event Sourcing are orthogonal concerns.

It's what it says on the tin - you have one model that manages a history, both applying updates to that history in response to commands and constructing from that history the responses to queries.

class BankAccount {
    final History<Transactions> transactions;

    void deposit(Money money) {...}
    Money computeInterestAccruedSince(Date lastReview) { ... }

}

I've yet to see a situation where you use ES without CQRS because this would only be the case if you do not need any query/analyses capabilities across more than 1 entity. 99% of all cases this is a requirement ;)

You will definately need something like CQRS if you want to query over multiple entities as you will apply a different way of querying your data other than using event sourcing. (unless you want to replay all events every time you query..) How you go about implementing the CQRS part isn't set in stone though. It just describes reading and writing are 2 seperate concerns handled in different ways.

So in general: No, this does not make any sense.

Yes, it does.

Basically, the entire idea of event-sourcing is just to store the changes that led to the current state, instead of storing the current state. This way, with event-sourcing, you automatically have a history and can run time-series analysis on your data, and try to learn from the past.

Whether you use CQRS is a completely different story: CQRS is about separating the writing to your application from reading from it.

In the same way you can use CQRS without event-sourcing, you can use event-sourcing without CQRS. Both are independent of each other, they just accidentally fit each other very well.