This is a very loaded question for which there is no single solution. Setting aside how and by whom your customisations are developed, then some other factors to consider would be
1. Are you using multiple environments to perform configurations and develop customisations?
2. Are you currently using managed solutions or everything unmanaged?
3. Do you regularly customise everything, so there isn't really a base set of entities you can group together?
The general convention is to create smaller solutions that are segmented, as you mention above, by having a "base" solution with all shared components, and you then have additional solutions with other components and their direct dependencies. This can also centralise where your base component customisations are made, and you can even employ further solution layering of these shared components if needed if, for example, you were adding a new field that is only needed by a single separate solution. The one downside to this is if you're continually making changes to this "base" solution (which then means you have to deploy this solution everytime with every release). You may decide to start branching off minor changes to this base solution by adding further managed solutions but then your ALM process starts becoming convoluted. It also becomes messier if you have segregated solutions by physical environments
Another option would be to segment your solutions by component type, e.g. one each for entities, one for flows, plugins, webresources. This makes your solutions more monolithic but your ALM is somewhat simpler. Unfortunately this make rollbacks more complicated and you would then have to employ patching to work around this (which ironically MS don't recommend anymore even this patching was their recommendation for when you needed to making bug fixes)
One thing to keep in mind with segmenting these solutions is the impact from solution layering as it could then become possible for a user to make an unmanaged customisation to a base entity and add those customisations to another unmanaged solution that becomes a managed solution. This would become especially prevalent if you use multiple environments to make customisations
Also, if you are using multiple environments for segmenting your solutions, you need to consider the ALM impact of keeping these solutions all in sync and the development time and effort e.g. if you need to add something to your base solution so that you can use it in another solution in another environment. This quickly becomes a bottleneck if you regularly need to make these kinds of additions, and people could start taking shortcuts by directly making the same customisation in the target environment instead to save time and deployment effort
