Reads and writes have different requirements: queries involve complex JOINs and aggregations; commands require transactional integrity. Separating them allows each to be optimised independently.
One database, but separate classes: CreateOrderCommand and OrderSummaryQuery. Minimal complexity, but already provides structure.
The write side stores events (Event Store); the read side builds denormalised projections suited for reading. High complexity, but full audit trail and the ability to "replay" state.
CQRS adds complexity. Justified in complex domains with different read/write loads. Unnecessary for CRUD applications.