Respuestas:
Las líneas pueden ser un poco borrosas, pero lo veo así:
Una clase / interfaz de servicio proporciona una forma de que un cliente interactúe con alguna funcionalidad en la aplicación. Esto suele ser público, con algún significado comercial. Por ejemplo, una TicketingServiceinterfaz puede permitírselo buyTicket, sellTicketetc.
Una clase auxiliar tiende a ocultarse del 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 DateConvertorcon un convertDateToTimestampmétodo que realiza este procesamiento.
Los servicios no solo están estrechamente vinculados a los DAO, es un patrón de término / uso más amplio que la persistencia
Las clases auxiliares no violan 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 cierto contexto dentro de la aplicación, mientras que los asistentes son más genéricos y no les importa a qué aplicación están ayudando.
Para mí, sigo la definición de Eric Evans,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 AccountAND a Customer.
Entonces, ahí es donde serviceentra un . Es donde pones el código que está en el Modelo de dominio pero que no pertenece naturalmente a una entidad / componente u otro.
Pienso en a helpercomo una especie de clase de estrategia. Para mí, es un lugar para poner código que necesita ser reutilizado por varias clases pero que podría no ser tan adecuado como métodos abstractos dentro de la jerarquía de las clases que lo usan. Personalmente, encuentro el término helperun poco vago y realmente no los tengo en mi modelo. Aunque existen en bibliotecas que yo uso.
Clase de servicio: Contiene lógica de negocios.
Clase auxiliar: esta clase es un tipo de componente reutilizable.
Mezcló dos principios no relacionados. Los servicios y las clases auxiliares no están conectados. Especialmente el término "clase de servicio" es engañoso. Creo que se refiere a un "servicio" que está en un nivel de abstracción más alto que las clases. Un servicio se caracteriza por
"un mecanismo para permitir el acceso a una o más capacidades, donde el acceso se proporciona utilizando una interfaz prescrita y se ejerce de acuerdo con las restricciones y políticas especificadas en la descripción del servicio".
Esta definición cambia ligeramente según 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 (a pesar de que es un antipatrón, ya que tienden a evolucionar a clases de blob o dios) que se refiere a una clase que encapsula operaciones genéricas (tenga en cuenta que esto está en un nivel inferior de abstracción y está conectado a la aplicación / conocimiento de la solución ). Soy consciente del hecho de que casi no existe ningún 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 son las múltiples definiciones de 'servicio' en DDD:
Servicio de aplicación: estos 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: Esto puede ser utilizado por el dominio o la capa de aplicación, y contiene lógica empresarial que no encaja perfectamente en una entidad en particular.
Servicio de infraestructura: el dominio los utiliza para comunicarse con recursos externos.
Las clases auxiliares tienden a contener fragmentos de código o algoritmos que serían reutilizados por múltiples entidades, por lo que no pueden entrar en entidades sin violar el principio DRY. Probablemente estén más cerca de los Servicios de dominio, ya que cumplen el mismo propósito (externalizar la lógica de negocios de las entidades) pero lo hacen por diferentes razones.