TLDR: There is no reason to use child workflows just for code organization. You can use OO and other code organization techniques to deal with the complexity.
Here are valid reasons to use a child workflow:
- A child workflow can be hosted by a separate set of workers that don’t contain the parent workflow code. So it would act as a separate service that can be invoked from multiple other workflows.
- A single workflow has a limited size. For example, it cannot execute 100k activities. Child workflows can be used to partition the problem into smaller chunks. One parent with 1000 children each executing 1000 activities gives 1 million activities executed.
- A child workflow can be used to manage a resource using its ID to guarantee uniqueness. For example, a workflow that manages host upgrades can have a child workflow per host (hostname being a workflow ID) and use them to ensure that all operations on the host are serialized.
- A child workflow can be used to execute some periodic logic without blowing up the parent history size. Parent starts a child which executes periodic logic calling continue as new as many times as needed, then completes. From the parent point of view, it is just a single child workflow invocation.
The main limitation of a child workflow versus collocating all the application logic in a single workflow is the lack of a shared state. Parent and child can communicate only through asynchronous signals. But if there is a tight coupling between them it might be simpler to use a single workflow and just rely on a shared object state.
I personally recommend starting from a single workflow implementation if your problem has bounded size in terms of the number of executed activities and processed signals. It is just simpler than multiple asynchronously communicating workflows.
Also, it is frequently overseen that workflows are not just functions, you can use the full power of OO in them. Use structures, interfaces, and other OO techniques to break the logic into more manageable abstractions.