In the past, I have set up a one to one relationship between solutions and applications. Mostly because that made the most sense for the project I was working on because the application would always be deployed and removed as a single unit of work. I can’t see a reason why you couldn’t have more solutions but I try to organize the applications more than the solutions.
If you are talking about a whole lot of artifacts, breaking it up would make sense more from a size point of view. It probably wouldn’t hurt to put the full deployment on each server since you never know when your Receive Server might need to be a Send Server plus then you’d have to build and maintain multiple installation packages.
I’d create a common shared application. Then have the others reference it.
I don’t have any hard set rules. The key is to make deployment and manageability easy and structure things logically. In the 2004 days (before applications), one project I was on had a few solutions, and about 40 projects. A few Orchestration, a few pipeline, and then many projects with schema and maps for vendors.
Hope this helps.