Creo que está confundiendo la responsabilidad individual con la segregación de la interfaz.
Desde la perspectiva de la interfaz cliente/servicio, debe mantener sus contratos delgados y en serio. Vea a continuación un ejemplo de eso.
En el lado de SRP, esto debería ser completamente interno para la implementación del servicio y el cliente no debería tenerlo en cuenta. Si su código de servicio es demasiado grande, divídalo en clases. Luego haga que su código de servicio, al menos inicialmente, actúe como una fachada y reenvíe todas las llamadas a los objetos relevantes. Más adelante, tiene la opción de dividir su servicio en múltiples servicios. Pero tenga en cuenta que SOA y el diseño orientado a objetos, aunque se superponen, están separados y tienen diferentes requisitos.
Ejemplo de segregación de interfaz: Tenemos un servicio aquí en el trabajo que usamos para realizar diversas funciones en algunos objetos comerciales. El servicio original tenía una interfaz. A medida que crecía, nos dimos cuenta de que teníamos tres familias de métodos: persistencia de objetos de datos, actualizaciones de negocios, análisis de negocios. Nos dividimos en tres contratos. Nuestro cliente/servicio implementa los 3, por lo que lo único que tuvimos que hacer fue dividir el contrato en tres y configurar dos puntos finales adicionales en nuestra configuración de WCF. Muy simple.
Espero que esto ayude.
¡Me pregunto sobre esto también! Solo estoy planeando nuestros contratos de servicio WCF, y dado que cada contrato debe ser pequeño y ser responsable de una unidad de trabajo contenida, podría terminar con cientos de contratos. Este no puede ser el punto, ¿verdad? – Sam