Our shop is attempting to move towards a more "distributed" architecture. I didn't want to use the term "SOA" because I'm not really sure if that's appropriate in our situation.
For each new feature that is developed, a new service (WCF in our case) is created specifically for that feature. A feature is defined as new functionality, which can be a brand new application or a new addition for an existing piece of software. As more features are added, the number of services that we need to maintain goes up. Each of these services are hosted in isolation and expose their own endpoint.
I don't have a lot of experience with distributed architectures or SOA in general, but this just feels wrong. Is there better way we can do this?
Instead of having separate services for each of these features, would it make more sense to logically group and consolidate some of these service into one large service and provide a "unified" API? Or would something like this tend to grow too large and become unwieldy/fragile?
Best Answer
One important aspect of SOA is that a SOA service is a commodity, or product. This isn't a technical issue, but a business issue. The same way you plan an application, consider it's clients demands etc.
The Business \ Product management overhead of developing a service should be similar to developing an application
Regarding the more "technical" aspects of your question.