Thanks for the questions!

1. Deletes generally just need an entity id, not a DTO. For a compound object like an Order, if the database supports it, I would set up a cascade delete. Otherwise you could query for the subobjects and explicitly delete them. In both cases I would hide all this logic inside the infrastructure component (API call wrapper) rather than exposing it to the domain logic.

2. Removing a line from an Order would be treated as an Update from the domain’s point of view. It depends whether you want to expose the logic to the domain layer. If you want to hide it, I would pass in the modified DTO without the line and then, inside the infrastructure component (the API call wrapper), figure out which lines are missing (delete), which lines are added (insert), and which lines are changed (update). This approach means that ANY updates to the aggregate root (additions, subtractions, etc) are handled the same way, using the same infrastructure method. More complicated, but it keeps the domain logic simple.

3. The problem of concurrent changes to the same aggregate is not specific to any particular design method and there are standard approaches you can use. If you have independent processes updating the database, you can use pessimistic concurrency (locks, transactions) or optimistic concurrency (versioning, timestamps). If everything is handled by one server (e.g. when doing microservices), then you can represent each aggregate root with an agent, and changes to the object are queued up and serialized that way. Or, yes, you can use event sourcing

Hope this helps!