Interesting hint. But I think what I mean is different.
Let me explain a simple (and really silly) example:
Let us assume we have some aggregate which holds a list of items (Like shopping cart or similiar).
Let us assume we have two commands.
The first lets us add an item and the business constraints to check are that the item is not already added. To implement this, we could just use a HashSet of the item keys to check wether the item was already added.
The second lets us remove an item. The business constraints to check are that only the last item can be removed (yes, I know that the command should be named "removeLast" in this case). To implement this we need an ordered list of the items to check if the one we should remove is the last. Later we decide that only the last added can be removed ever. Then we don't need the list, but only to remember the last added to check.
Of cource we could implement both commands in our aggregate and hold both the Hashset and the List (or the last added) in it, or go only with the list in both commands (complicating the implementation of the add check).
My idea now is, to have separate classes to implement this two commands and its constraints and each of them has its own optimized data structure that is best suited for their implementation. And both are hydrated from the same events (like 2 projections) handle a command and fire events (eg. ItemAdded, ItemRemoved).
This could also decouple and focus the implementation of very complex operations a bit.
What are the reasons (I think there are) not to do this?