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?

Also note that the "one thing" for a solution might be "Allow the user to frobnication effectively by integrating all those good, related, but separate things into a single coherent interface".
–
Joachim SauerJan 21 '13 at 15:54

1

I'm not sure if i get the question completely right. You have already designed a service with 'good architecture' and now someone want to have everything from one interface? So you just take all of your simple, well designed parts of your program and let users call them via one, big, interface? If that's the case, go for it. All of the parts are well designed, have a single responsibility, are interchangeable and so on - you only have one facade for the user that violates this principle. You should be fine.
–
mriJan 21 '13 at 20:11

2 Answers
2

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.

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.

Thank you - does your experience show that creating a service like mycompany.com/api/[everyMethodPossible] is an output of good software design or not? To me using SOLID principals applied to this use case indicates the answer is 'no'. Doing everything in a single container is a recipe for bad software. However I'm not 100% clear and thus my question here. Thank you for your help.
–
atconwayJan 21 '13 at 19:33

1

@atconway - not really, but it's not like a god object or even namespace pollution. You're not really doing everything in a single container, you're simply exposing cohesive parts of the api in a common location. Or at least that's the best case.
–
TelastynJan 21 '13 at 20:48