Comment by le-mark
2 months ago
This is an admirable goal but complicated by the inevitable conditional logic around what to do in certain situations. Push the conditions into the sub methods, or keep them in primary method? Thinking about what are testable chunks of logic can be a valuable guide. A lot of discipline is required so these primary methods dont become spaghetti themselves.
The testability angle is the deciding factor for me. Business logic that can be tested without the full pipeline context goes in sub methods. Orchestration decisions stay in the primary method.
Concrete example: "is this a transfer between accounts?" is pure business logic - takes a transaction and a list of bank accounts, returns true/false. That gets its own function with its own tests.
But "if it's a transfer, skip VAT calculation and use a different account mapping" is orchestration. Pushing that into the transfer detection function means it now needs to know about VAT and account mapping, which breaks isolation. Keeping it in the primary method means you can see all the skip/branch decisions in one place.
The spaghetti risk is real. What helps: keeping the orchestrator as declarative as possible. "if transfer detected, result = handleAsTransfer()" rather than inline logic. The primary method becomes a readable list of conditions and delegations, not nested logic.