¿Me gustaría saber qué diferencia a una clase de servicio de una clase de utilidad o una clase auxiliar? ¿Una clase solo con métodos subyacentes llama a la dao es un servicio? ¿El uso de las clases de ayuda no viola el SRP?
¿Me gustaría saber qué diferencia a una clase de servicio de una clase de utilidad o una clase auxiliar? ¿Una clase solo con métodos subyacentes llama a la dao es un servicio? ¿El uso de las clases de ayuda no viola el SRP?
Las líneas pueden ser un poco borrosas, pero lo veo de esta manera:
Una clase / interfaz de servicio proporciona a un cliente la forma de interactuar con algunas funciones de la aplicación. Esto es típicamente público, con algún significado comercial. Por ejemplo, una interfaz TicketingService podría permitirte buyTicket , sellTicket y así sucesivamente.
Una clase auxiliar se oculta al cliente y se usa internamente para proporcionar un trabajo de placa de caldera que no tiene un significado de dominio comercial. Por ejemplo, supongamos que desea convertir una fecha en una marca de tiempo para guardarla en su almacén de datos en particular. Es posible que tenga una clase de utilidad llamada DateConvertor con un método convertDateToTimestamp que realiza este procesamiento.
Los servicios no están simplemente acoplados estrechamente a los DAO, es un patrón de uso / término más amplio que la persistencia
Las clases de ayuda no violan el SRP si se codifican de acuerdo con ese principio. Es decir, cada método debe hacer una cosa y una cosa bien, la clase debe realizar un tipo de ayuda de utilidad (por ejemplo, conversión de fecha) y hacerlo bien.
No es una definición científica, pero mi opinión general es que una clase de servicio tiene algún contexto dentro de la aplicación, mientras que los ayudantes son más genéricos y no les importa a qué aplicación estén ayudando.
Para mí, voy por Definición de Eric Evans de service que es algo como esto:
En general, en un sistema bien diseñado, la mayoría de las clases (en el Modelo de dominio) tienen una responsabilidad o función bastante clara en el sentido de que tratan con una entidad específica o un conjunto de entidades en el modelo.
es decir,
Cuando tiene una funcionalidad que no pertenece a ninguna entidad en particular, puede ser difícil encontrar un lugar correcto para que se siente. Es decir, algo que encapsula un proceso que involucra tanto un Account Y un Customer .
Entonces, ahí es donde entra service . Es donde se coloca el código que está en el Modelo de dominio pero que, naturalmente, no pertenece a una entidad / componente u otro.
Creo que un helper es un tipo de clase de estrategia. Para mí, es un lugar para colocar código que necesita ser reutilizado por varias clases, pero puede que no sea lo suficientemente bueno como métodos abstractos dentro de la jerarquía de las clases que lo usan. Personalmente encuentro que el término helper es un poco vago y realmente no los tengo en mi modelo. Aunque existen en las bibliotecas que utilizo.
Clase de servicio: Contiene lógica empresarial.
Clase de ayuda: esta clase es un tipo de componente reutilizable.
Mezclaste dos principios no relacionados. Los servicios y las clases de ayuda no están conectados. Especialmente el término "Clase de servicio" es engañoso. Creo que se está refiriendo a un "Servicio" que está en un nivel más alto de abstracción que las clases. Un servicio se caracteriza a través de
"un mecanismo para permitir el acceso a una o más capacidades, donde el El acceso se proporciona mediante una interfaz prescrita y se ejerce consistente con las restricciones y políticas especificadas por el servicio descripción. "
Esta definición cambia ligeramente dependiendo de su contexto. Sin embargo, el punto crítico es que el término "servicio" está en un nivel abstracto , el nivel de arquitectura y conocimiento del dominio . La "clase auxiliar" es un patrón de diseño (aunque es un antipatrón, ya que tienden a evolucionar a clases de dioses o blob) que se refiere a una clase que encapsula operaciones genéricas (observe que esto se encuentra en un nivel inferior de abstracción y está conectado a conocimiento de la aplicación / solución ). Soy consciente del hecho de que casi no existe software que no contenga ningún tipo de clase auxiliar, pero aún así, es una mala práctica.
Una cosa a tener en cuenta es las múltiples definiciones de 'servicio' en DDD:
Servicio de aplicación: se ubican en la capa de aplicación y se comunican con el dominio y la capa de datos, son la interfaz a través de la cual los sistemas externos / UI interactúan con el sistema DDD.
Servicio de dominio: puede ser utilizado por el dominio o la capa de aplicación, y contiene lógica de negocios que no encaja perfectamente en una entidad en particular.
Servicio de infraestructura: el dominio los utiliza para comunicarse con recursos externos.
Las clases de ayuda tienden a contener partes de código o algoritmos que serían reutilizados por varias entidades, por lo que realmente no pueden ingresar entidades sin violar el principio DRY. Probablemente sean los más cercanos a los Servicios de Dominio, en el sentido de que cumplen el mismo propósito (externalizar la lógica empresarial de las entidades) pero lo hacen por diferentes motivos.
Lea otras preguntas en las etiquetas domain-driven-design design java