In a screen that displays many order detail lines of order, users can add, update, or delete rows or columns and then click the "Save" button to save all the order changes in one transaction.
Option 1: Create one Command (which will be created by the Clicking event of the button), saying UpdateOrderCommand, which has complex internal data structures for all the changes. And the command will apply the changes to the database table. (So the UI part code will need to track all the changes for the command.)
Option 2: Create AddOrderLineCommand, DeleteOrderLineCommand, UpdateOrderLineCommand, and SaveOrderCommand. And every operation on the UI will create a request and the "Save" button will invoke SaveOrderCommand. However, it will need some stateful service to keep all the unsaved changes.
Which one is CQRS idiomatic approach?
This mostly a preference based question but there are some guidelines that I'm following based on various thought processes.
CQRS should be transparent
The one who consumes the data that is updated/read this way, has no need to know that it is done by using CQRS. Maybe eventual consistency, but there is no need to indicate it by exposing commands in a certain way.
REST api access
When I create commands to access the Domain, it's much easier. It's just resource and verb naming do its much easier. This being the case I want my commands to match the functionality. I don't want to have 100 endpoints using the same save all command.
Being in the OOP world, this also violated the single responsibility, making a good class.
Ubiquitous language
You are in a Domain Driven World. Your code should use the same business language. SaveAll means nothing to business, nothing to a new developer and probably nothing to you.