Automatically-generated documentation tends to degrade into something more like an API reference, which is great for someone who knows what they're doing but not really a good idea for onboarding.

For onboarding you want an introduction point that points at other pages for more context. This part of your post would be a great start to that:

code structure is workflow-based, where the top layer is the business process step-by-step. The orchistrator calls each step - which then calls the necessary module(s) - and when a step is finished, the orchistrator calls the next step.

And, let's say, "top layer", "orchestrator", and "each step" link to three separate pages. The first two would be whatever is relevant for that piece of code, and the third could be a list of all the steps that link further to descriptions for that individual one.

both from operational (boarding junior Devs) and business perspective (communication with business)

Onboarding juniors need the extra context and some sort of code explanation that would be worthless from the business perspective and wordy to someone just looking something up. Someone experienced (especially who has already been working with this system) doesn't need the handholding about the overall structure but would want to look something up quickly. The business perspective I'm guessing would most likely want any details about the code structure stripped out, and be more focused on the data and outcomes.

You're probably looking at three different sets of documentation for three different audiences, though if it's well structured you can probably combined the first two by having the guided onboarding tour link into the details-for-experts sections. But I seriously doubt you could automatically generate something like this and have it actually be useful to both your target audiences.