¿Qué tan esencial es hacer una capa de servicio?

El libro de Martin Fowler "Patrones de arquitectura empresarial" dice:

  

La pregunta más fácil de responder es probablemente cuando no se usa. Probablemente no necesite una capa de servicio si la lógica de negocios de su aplicación solo tendrá un tipo de cliente, por ejemplo, una interfaz de usuario, y las respuestas de su caso de uso no implican múltiples recursos transaccionales. [...]

     

Pero tan pronto como imagina un segundo tipo de cliente, o un segundo recurso transaccional en respuestas de casos de uso, vale la pena diseñar en una capa de servicio desde el principio.

Los beneficios que proporciona una capa de servicio es que define un conjunto común de operaciones de aplicación disponibles para diferentes clientes y coordina la respuesta en cada operación. Cuando tiene una aplicación que tiene más de un tipo de cliente que consume su lógica empresarial y tiene casos de uso complejos que involucran múltiples recursos transaccionales, tiene sentido incluir una capa de servicio con transacciones administradas.

Con CRM, Ventas e Inventario, habrá una gran cantidad de casos de uso de tipo CRUD de los cuales casi siempre hay una correspondencia de uno a uno con las operaciones de la capa de servicio. Las respuestas a la creación, actualización o eliminación de un objeto de dominio deben coordinarse y tramitarse de forma atómica mediante las operaciones de la capa de servicio.

Otro beneficio de tener una capa de servicio es que puede diseñarse para invocación local o remota, o ambas cosas, y le brinda la flexibilidad para hacerlo. El patrón sienta las bases para la implementación encapsulada de la lógica de negocios de una aplicación y la invocación de esa lógica por parte de varios clientes de manera consistente. Esto significa que también reduce / elimina la duplicación de código, ya que sus clientes comparten los mismos servicios comunes. También puede reducir los costos de mantenimiento, ya que cuando la lógica de su negocio cambia, usted (generalmente) solo necesita cambiar el servicio, y no cada uno de los clientes.

En resumen, es bueno usar una capa de servicio, más aún, creo que en su ejemplo ha proporcionado, ya que parece que tiene varios clientes de lógica empresarial.

Agregando una capa de servicio porque ha evaluado la idea y ha concluido que es el mejor enfoque: good

Agregar una capa de servicio porque eso es lo que hacen todos los niños geniales: bad

Si tu instinto dice que no necesitas uno, entonces no hagas uno.

Uno de los desarrollos más decepcionantes en el mundo de la programación en los últimos 10 años más o menos es que se ha convertido en una orientación de moda, con gente siguiendo tendencias y carros como si fueran los zapatos de esta temporada. No caigas en esa trampa. Porque la próxima temporada 'todos' te dirá que deberías haberlo diseñado de otra manera.

No hay nada malo o correcto con una capa de servicio: es un enfoque particular cuya idoneidad debe evaluarse en cuanto a los méritos técnicos para el proyecto en cuestión. No se sienta obligado a sustituir las opiniones de otras personas por su propio criterio.

Hay muchos factores que intervienen en la decisión de crear una capa de servicio. He creado capas de servicio en el pasado por los siguientes motivos.

1. Código que debe ser reutilizado por varios clientes.
2. Bibliotecas de terceros para las que tenemos licencias limitadas.
3. Terceros que necesitan un punto de integración en nuestro sistema.
4. Centralizar la lógica de negocios duplicada.

Caso 1: está creando una funcionalidad base que debe ser utilizada por una gran cantidad de clientes diferentes. La capa de servicio incorpora funcionalidad para que diferentes clientes puedan acceder a la funcionalidad proporcionada de inmediato.

Caso 2: Normalmente, usted aloja el código en el espacio de la aplicación pero está utilizando una biblioteca de terceros para la cual tiene licencias limitadas. En este caso, tiene un recurso que le gustaría usar en todas partes, pero solo un número limitado de ellos. Si lo hospeda detrás de un servicio, toda la organización puede utilizarlo desde sus aplicaciones sin tener que comprar una licencia para cada hosting individual.

Caso 3: está creando funcionalidad para que terceros se comuniquen con usted. En su ejemplo, podría configurar un punto final de inventario para permitir que los proveedores le pasen mensajes sobre los envíos de productos entrantes.

Caso 4: ha analizado su código en toda la empresa y encontró que equipos separados han creado lo mismo (solo implementado de forma ligeramente diferente). Con una capa de servicio, puede elegir los mejores enfoques y ahora puede implementar el proceso de la misma manera en todos los equipos haciendo que llamen al servicio. Otro beneficio de la lógica centralizadora es cuando se encuentran errores. Ahora puede implementar la solución una vez y todos los clientes disfrutan del beneficio al mismo tiempo.

Dicho todo esto, hay potenciales negativos para una capa de servicio.

1. Agrega complejidad al sistema. Donde antes solo tenías una aplicación para depurar ahora tienes dos. Los problemas de producción requieren la comprobación de la configuración de la aplicación cliente, la configuración de la aplicación de servicio o los problemas de comunicación entre las aplicaciones cliente y servidor correctamente configuradas. Esto puede ser complicado si nunca lo has hecho antes.
2. Un punto de falla. Si tiene una interrupción del servicio, todos los clientes se ven afectados. Cuando el código no se implementa de esta manera, el riesgo puede ser menor (aunque hay formas de mitigar esto).
3. Las versiones pueden ser más difíciles de hacer. Cuando tiene una aplicación que utiliza un servicio, los cambios en la interfaz se pueden hacer al mismo tiempo entre los dos. Cuando ahora tiene varios clientes, debe administrar quién está en V1, quién está en V2 y coordinar la eliminación de V1 (una vez que sepa que todos se han actualizado a V2).

El punto principal es que no siempre es un éxito para que su sistema esté orientado al servicio. En mi experiencia, generalmente es una buena idea (tiendo a estructurar las aplicaciones de esta manera), pero no es una decisión automática. Al final del día, debe sopesar los pros y los contras y tomar la decisión correcta para su situación.

La mayoría de las capas de servicio que he visto son un completo desastre. Los servicios tienden a tener muchos métodos diferentes, 1500 LOC no son raros. Los diferentes métodos no tienen nada en común, pero comparten código. Esto da como resultado un alto acoplamiento de , bajo cohesion . También viola OCP , porque cada vez que se necesita una nueva operación, tiene que modificar el código en lugar de extender el base de código Una capa de servicio bien construida es teóricamente posible, pero nunca la vi en la práctica.

CQRS resuelve estos problemas y evita que tengas que crear una de esas capas de servicios de procedimiento.

Agregar una interfaz (una capa de servicio es un tipo de interfaz) lleva tiempo. Una buena toma mucho tiempo para diseñar y probar. Es muy importante hacerlo bien en el primer intento porque cambiarlo más tarde rompe a todos los clientes. Además, tenga en cuenta que probablemente no sabrá qué debe haber en esa interfaz hasta que tenga un segundo cliente con necesidades ligeramente diferentes. Mantener un servicio es un proyecto interminable en sí mismo.

En la mayoría de las organizaciones, si visita a su patrocinador comercial y les pregunta: "¿Desea que otros departamentos obtengan el beneficio de (reutilizar) este sistema que estamos desarrollando con su presupuesto?" se reirán de ti Póngalo en funcionamiento para su patrocinador comercial primero, luego comience a jugar con la reutilización de ese código (en el tiempo que le corresponda a su departamento).

Si sabe, de hecho, la funcionalidad que está escribiendo hoy será reutilizada por varios clientes de servicio diferentes, luego considere diseñar una capa de servicio desde el primer día. Si no está seguro, o ya hay muchas incógnitas en el proyecto, primero consiga algo simple y sepárelo en servicio y cliente más tarde si tiene tiempo y presupuesto. Es mucho más fácil obtener la interfaz de servicio en el primer intento cuando comienza con un sistema en funcionamiento.

P.S. Si está trabajando en Java, Joshua Bloch tiene muchos consejos fantásticos de interfaz a lo largo de su libro, Effective Java.

Estoy de acuerdo contigo. No es necesario incluir una capa más si está utilizando una única interfaz de usuario.

DAL, BL y UI / Controller son una buena combinación para diseñar una aplicación. Si planea utilizar una única interfaz de usuario, no es necesario preparar una capa adicional. Incluir 1 capa más en la aplicación solo aumenta los esfuerzos / tiempo de desarrollo.

Otro schenerio es usar múltiples IU en tu aplicación, es bueno tener una capa de servicio para manejar las IU en este caso.

Desbordamiento de pila: Discusión sobre el patrón de la capa de servicio

Yo diría que tu BL es tu capa de servicio. Un lugar central donde se asienta su lógica empresarial. Esta debe ser una DLL que pueda ser utilizada por cualquier cosa que necesite esa lógica. Luego, puedes poner una capa de API en la parte superior de la misma si tu aplicación tendrá una interfaz de usuario diferente.