If you want to change this code, first write unit tests that validate it's functionality. Then as you make changes you will have confidence that you haven't broken anything.

There is no hard and fast rule about numbers of lines, but a function with 40+ lines is certainly a hint that it is too long. A function with 2 lines is not too small. Steve McConnell's Code Complete 2 refers to some studies and says that 200 lines is the upper limit for readability.

It's all about cohesion. A single function should do a single task, and all parts of the function should relate directly to performing that task.

Consider cyclomatic complexity. A high number of decision points and deep nesting may indicate too much code in one function.

Also, well-selected function and parameter names make code more readable because they act as a form of documentation. Everything that a function does should be immediately obvious from reading its name and its parameters. If it's hard to explain what a function does in a few comment lines, then you probably have too much code in one function.

Tackling a significant refactor requires you to have a solid understanding as to why you're performing that refactor.

I'll rule out the hobby level justifications such as "make the code more pure" or "improve stylistic expression" or similar. Those aren't bad justifications, but a commercial project will almost never see or use that level of justification for a major undertaking.

In contrast, commercial level refactoring justification always involves pain.

• "Maintenance has become impossible."
• "The code base can't be extended."
• "Code changes generate obscure errors in unanticipated areas of the code."

Pain justifies the expense and risk involved. And pain leads you to your answer. You refactor in order to minimize future pain. Refactor in order to encapsulate the change.

You mentioned a couple of aspects such as communication systems, orders, and shipments. And you correctly called out that there isn't a one-size-fits-all approach to identify what belongs where. Every system is different based upon its domain and business need.

For your system, identify what is changing. Push that into its own vertical that conforms to a contract or an API with the rest of the system. Whenever that section changes, you can verify it still meets its contract and control the amount of damage from the code change.