The most useful of answers: It depends.

The aggregates that are attached to the Company, if they receive commands from sources other than the Company aggregate then you could have a race condition where you told the Company to close, and the Process manager turns to another aggregate to shut it down, but cannot or should not because it’s in the middle of its own workflow – if that workflow ever tried to call a command back on the closed Company, you might have some problems, especially if the event was billable or otherwise very important.

Non exhaustive list of options:

• You just close up children aggregates even if they’re in the middle of something because.. it’s fine in your case
• The PM could handle these errors (upon calling child aggregate it gets back an unexpected response, perhaps it could reopen the company, or something.) In the meantime the company is closed and acts/is projected that way, but attached aggregates may be busy dealing with their own commands/events.
• You set the company in a ‘closing’ state (like you suggested with CompanyUnitCloseProecssStarted) where the PM would finalize the shutdown, send a ‘complete’ command to the Company and then itself shutdown on a CompanyUnitCloseProcessCompleted -type event. This helps minimize the possible events/commands that children aggregates might be orchestrating before the Company is marked as ‘closed’.

The asyncness of the event sourced process can require complex solutions, and you can refactor the commands/events/processes in several ways each with their own failure modes. The main question is what guarantees do you need? That should drive your implementation.