Colleagues, how do you structure complex use cases in your Go projects? We are using a DDD approach. I’ve encountered a scenario where a single core business operation needs to trigger multiple additional actions: semantic chunking, handling funds deduction, generating personalized instructions for a user, launching a heavy asynchronous process, and monitoring its execution.

It’s important not to turn the main use case into a “god object.” I tried splitting the large use case into separate operations and injecting them via interfaces within the same use case. These components don’t call each other directly, but:

• the main orchestrator still remains overloaded;

• the number of dependencies (even though they are interfaces) keeps growing;

• it feels like this setup will only get harder to maintain in the future.

I’m interested in how other developers structure similar scenarios in Go.

Any real-world architectural examples or best practices would be appreciated.