Can I apply SOLID concepts to entire solution designs rather than just the internal components?

Question

So maybe the quick answer is 'Yes' absolutely (or no I suppose), but let me explain my question angle to get a better derived answer.

We all commonly use SOLID design principals when making up the pieces and parts of our applications. Don't make a class do too many things, don't make an Interface too large, use abstraction not concretions, etc.

Is it OK to apply this mentality at an abstract level when thinking about solutions, services, etc.? The main problem: I'm struggling with the request to have a single service do all things related to a specific business domain. Add to this multiple teams would all have their hands in the pot of the same application to add whatever functionality needed.

I have a service being built out with many good architecture and design principals in mind and believe totally that lots of 'additional' functionality could be bolted on vertically within the same framework and solution. After all this one of the reasons why we spend time architecting solutions to be loosely coupled and allow scalability with rather ease. So you might say, "go for it, if the framework can handle it then add away!"

Something is not sitting right with me and I would be concerned with a behemoth of an application/service that tries to do everything. I tried doing searches about "applications that do too much" or "services that have too many responsibilities" but not much came up. When I start thinking about the SOLID principals, I think having a service that does everything related to a specific business domain might not be a good idea and may cause issues on down the road with maintainability and stepping on each other's toes.

Is it correct to use SOLID principals when looking at entire solution functionality? Is creating a service like http://www.mycompany.com/api/[everyMethodPossible] correct, or could I be doing something that is incorrect?

Thanks!