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!
3
The reason design principles are so helpful and why it’s unfortunate people conflate them with patterns is because a design priciple is simply that; a principle for design; all design.
You can and should apply design principles to all things that require design, they’re truly cross-cutting (buzzwords yay!).
For example, Principle of Least Astonishment was created and described always for UI designers to ensure they present a UI that doesn’t cause users to make mistakes. It can however be applied to all contract definitions by developers, it can really be applied to anything, that’s why the classic example is the elevator button; one with an up arrow that calls the elevator to go down is poor design.
If design principles can be applied to a UI, and an elevator, then honestly anything that is to be designed can have them applied. Imagine if a car’s roll-down-window button also turned on the vent because it thinks you want fresh air, sounds like bad design right? Single responsibility principle; any buttons in a car that do multiple things would just seem weird to a user.
Even LSP can be defined beyond code, think about a common type of thing? Say a taxi cab. Now for a taxi cab you call them and they show up when you request, a taxi cab that is always 15 minutes late violates LSP because you always expect all taxi cabs to be on-time, if you expected them all to be 15 minutes late it wouldn’t violate LSP because it would follow the rules of the common-type taxi cab.
Open-Closed principle is observable in the design of cars, they have a base model closed for modification but open for extension with a roof rack, keyless entry, clear-coat, side runners etc. The vehicle was designed to allow for those extensions, but it was designed to be closed for modification which is why it takes a mechanic to change the drive-train to AWD and isn’t easy even for him. It wasn’t designed to be modified in this way, but it was designed with relevant extension points.
Full-scale systems themselves at a macro level should definitely take these into account, a single process service that is side-effect free with a single responsibility is great to have for certain things and follows many of these, have as many of those as you want. A service that does a ton of things all on it’s own is however a violation of SRP.
Is it correct? No.
Correctness has nothing to do with it. The SOLID principles are good, and can be applied outside of OO, like in software architecture or writing functions. Personally, I find them to be useful in doing architecture scoped design, but remember that the goal is to make good software, not to provide the right answers to a test.
2