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

Comencé a crear una aplicación en 3 capas (DAL, BL, UI) [maneja principalmente CRM, algunos informes de ventas e inventario].

Un colega me dijo que debo pasar al patrón de capa de servicio, que los desarrolladores llegaron al patrón de servicio desde su experiencia y que es el mejor enfoque para diseñar la mayoría de las aplicaciones. Dijo que sería mucho más fácil mantener la aplicación en el futuro de esa manera.

Personalmente, tengo la sensación de que solo está haciendo las cosas más complejas y no podría ver mucho beneficio que justifique eso.

Esta aplicación tiene una pequeña interfaz de usuario parcial adicional que usa algunas (pero solo pocas) de las funciones de la aplicación de escritorio, por lo que me encontré duplicando algo de código (pero no mucho). Solo por alguna duplicación de código, no lo convertiría para que esté orientado al servicio, pero dijo que debería usarlo de todos modos porque en general es una muy buena arquitectura, ¿por qué los programadores son tan apasionados por los servicios?

Traté de buscar en Google, pero todavía estoy confundido y no puedo decidir qué hacer.

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

La pregunta más fácil de responder es probablemente cuándo no usarla. 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 sus respuestas de casos de uso no involucran múltiples recursos transaccionales. [...]

Pero tan pronto como visualice 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á muchos casos de uso de tipo CRUD de los cuales casi siempre hay una correspondencia 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 ser coordinadas y transaccionadas atómicamente por 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, 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. Potencialmente, también puede reducir los costos de mantenimiento, ya que cuando cambia la lógica de su negocio, (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, así que creo que en su ejemplo ha proporcionado, ya que parece que tiene varios clientes de lógica empresarial.

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

Agregar una capa de servicio porque eso es lo que están haciendo todos los niños geniales: malo

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

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 vuelto molestamente orientado a la `` moda '', con personas que siguen las tendencias y los vagones como si fueran los zapatos de esta temporada. No caigas en esa trampa. Porque la próxima temporada 'todos' te dirán 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 función de sus méritos técnicos para el proyecto en cuestión. No se sienta obligado a sustituir las opiniones de otras personas por su propio juicio.

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

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. Centralización de lógica comercial duplicada.

Caso 1: está creando una funcionalidad básica que debe ser utilizada por una miríada de clientes diferentes. La capa de servicio incorpora funcionalidades para que diferentes clientes aprovechen su funcionalidad provista de inmediato.

Caso 2: normalmente 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 aloja detrás de un servicio, toda su organización puede usarlo desde sus aplicaciones sin tener que comprar una licencia para cada alojamiento 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 envíen mensajes sobre los envíos de productos entrantes.

Caso 4: ha analizado su código en toda la empresa y descubrió que equipos separados han creado lo mismo (solo implementado de manera 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 al hacer que llamen al servicio. Otro beneficio de la lógica de centralización 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ía una aplicación para depurar ahora tiene dos. Los problemas de producción requieren verificar 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 configuradas correctamente. 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. El control de versiones puede ser más difícil de hacer. Cuando tiene una aplicación que usa un servicio que implementa la interfaz, los cambios se pueden hacer al mismo tiempo entre los dos. Cuando tenga varios clientes ahora, 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 slam dunk orientar el servicio de su sistema. 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 , baja cohesión . También viola OCP , porque cada vez que se necesita una nueva operación, debe modificar el código en lugar de extender la base del 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 tenga que crear una de esas capas de servicio 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 daña a todos los clientes. Además, tenga en cuenta que probablemente no sabrá qué necesita estar 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 acude al patrocinador de su empresa y le pregunta: "¿Desea que otros departamentos se beneficien (reutilicen) este sistema que estamos desarrollando con su presupuesto?" Se reirán de ti. Primero, haga que funcione para el patrocinador de su negocio, luego comience a jugar con la reutilización de ese código (en el tiempo de su departamento).

Si sabe, de hecho, que la funcionalidad que está escribiendo hoy será reutilizada por varios clientes de servicio diferentes, entonces 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, haga que algo simple funcione primero y luego sepárelo en servicio y cliente 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.

PD: si está trabajando en Java, Joshua Bloch tiene muchos consejos de interfaz fantásticos 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. La inclusión de 1 capa más en la aplicación solo aumenta los esfuerzos de desarrollo / tiempo.

Otro esquema es usar múltiples IU en su 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 sienta su lógica de negocios. Esto debería ser una DLL que pueda ser utilizada por cualquier cosa que necesite esa lógica. Luego, puede colocar una capa de API web encima de eso si su aplicación tendrá UI diferentes.