Arquitectura de servicios web: ¿servicios múltiples y conexiones de bases de datos múltiples? - servicios web

¿Podría alguien por favor dirigirme a algo buenodocumentación o comentarios aquí sobre cuáles son las mejores prácticas para implementar servicios web en una aplicación que maneja diferentes preocupaciones? Por ejemplo, ¿debería crear diferentes servicios, uno que maneje la seguridad, (AuthService), uno que maneje la entrada de datos para los representantes de servicio al cliente, (CRUDService), BillingService, etc., o simplemente debería encapsular todos estos "servicios" en uno, p.ej ApplicationService? Básicamente, estoy preguntando si es un mal diseño crear múltiples servicios (archivos) dentro de una aplicación. ¿Pueden algunos de ustedes notar sus experiencias o lo que han experimentado? Además, supongamos que tres de los servicios enumerados desde arriba se conectan a la misma base de datos, pero en realidad están enfrentando preocupaciones totalmente diferentes, por ejemplo, una es para todas las transacciones como CRUD, y la otra es para fines puramente informativos. Debo crear dos servicios aquí, un CRUDService y el otro para ReportingService? ¿Es malo crear dos conexiones de base de datos diferentes a través de estos 2 servicios? ¿O cómo puedo compartir la misma conexión de base de datos con diferentes servicios?

Respuestas

Creo que hay una tendencia entre lo públicoservicios disponibles para volcar todo en un solo servicio. Lo cual, puede no ser una mala idea para una API disponible públicamente. Simplemente hace que sea más fácil para los desarrolladores. Sin embargo, para cualquier proyecto en el que trabajo, trato de dividir las cosas en grupos lógicos. De esta manera, su cliente no necesita heredar la funcionalidad que puede no necesitar. Actualizar los servicios también sería una tarea un poco más fácil porque solo está afectando un cierto subconjunto de su marco de servicios web y no todo. Por lo tanto, si su contrato de servicio se rompe y sus clientes ya no lo admiten, aún pueden usar otras partes de su sistema, pero no esa en particular. Donde, como si rompieras un contrato en tu servicio agregado, todo falla. Finalmente, si tiene que implementar algo como un soporte de conmutación por error, tiene más flexibilidad para elegir qué servicio requiere más nodos de conmutación por error, lo que le permite administrar mejor la asignación de recursos.

Si desea mejores prácticas, eche un vistazo a Catálogo de patrones de diseño SOA