Respostas:
As linhas podem ficar um pouco embaçadas, mas eu vejo da seguinte maneira:
Uma classe / interface de serviço fornece uma maneira de um cliente interagir com algumas funcionalidades do aplicativo. Isso geralmente é público, com algum significado comercial. Por exemplo, uma TicketingServiceinterface de pode permitir que você buyTicket, sellTickete assim por diante.
Uma classe auxiliar tende a ser oculta do cliente e é usada internamente para fornecer algum trabalho de placa da caldeira que não tem significado no domínio comercial. Por exemplo, digamos que você deseje converter uma data em um carimbo de data e hora para salvá-la em seu armazenamento de dados específico. Você pode ter uma classe de utilitário chamada DateConvertorcom um convertDateToTimestampmétodo que executa esse processamento.
Os serviços não são simplesmente fortemente acoplados aos DAOs; é um padrão de uso / termo mais amplo que a persistência
As classes auxiliares não violam o SRP se codificadas de acordo com esse princípio. Ou seja, cada método deve fazer uma coisa e uma coisa bem, a classe deve executar um tipo de ajuda do utilitário (por exemplo, conversão de data) e fazer isso bem.
Não é uma definição científica, mas minha opinião geral é de que uma classe de serviço tem algum contexto no aplicativo, enquanto os auxiliares são mais genéricos e não se importam com o aplicativo que estão ajudando.
Para mim, eu entendo a definição de Eric Evans,service que é algo como isto:
Geralmente, em um sistema bem projetado, a maioria das classes (no Modelo de Domínio) tem uma responsabilidade ou função bastante clara, pois lida com uma entidade específica ou conjunto de entidades no modelo.
ie
Quando você tem uma funcionalidade que não pertence a nenhuma entidade em particular, pode ser difícil encontrar um local correto para ela ficar. Ou seja, algo que encapsula um processo que envolve um AccountAND a Customer.
Então, é aí que serviceentra um . É onde você coloca o código que está no Modelo de Domínio, mas que naturalmente não pertence a uma entidade / componente ou outro.
Penso helperem uma espécie de classe de estratégia. Para mim, é um lugar para colocar código que precisa ser reutilizado por várias classes, mas que pode não funcionar bem como métodos abstratos dentro da hierarquia das classes que o usam. Pessoalmente, acho o termo helperum pouco vago e realmente não o tenho no meu modelo. Embora eles existam nas bibliotecas que eu uso.
Classe de serviço: Contenha lógica de negócios.
Classe auxiliar: essa classe é um tipo de componente reutilizável.
Você misturou dois princípios não relacionados. Os serviços e as classes auxiliares não estão conectadas. Especialmente o termo "Classe de Serviço" é enganador - acho que você está se referindo a um "Serviço" que está em um nível de abstração mais alto que as classes. Um serviço é caracterizado por
"um mecanismo para permitir o acesso a um ou mais recursos, em que o acesso é fornecido usando uma interface prescrita e é exercido de forma consistente com as restrições e políticas especificadas na descrição do serviço."
Essa definição muda ligeiramente, dependendo do seu contexto. No entanto, o ponto crítico é que o termo "serviço" está em um nível abstrato , no nível da arquitetura e no conhecimento do domínio . A "Classe Auxiliar" é um padrão de design (embora seja um antipadrão, pois eles tendem a evoluir para classes de blob ou god), referindo-se a uma classe que encapsula operações genéricas (observe que este está em um nível mais baixo de abstração e está conectado para a aplicação de conhecimentos / solução ). Estou ciente do fato de que quase não existe software que não contenha nenhum tipo de classe auxiliar, mas ainda assim, é uma prática ruim.
Uma coisa a ser cautelosa são as múltiplas definições de 'serviço' no DDD:
Serviço de aplicativo: eles ficam na camada de aplicativo e se comunicam com o domínio e a camada de dados; eles são a interface através da qual sistemas / UI externos interagem com o sistema DDD.
Serviço de Domínio: pode ser usado pelo domínio ou pela camada de aplicativo e contém lógica de negócios que não se encaixa perfeitamente em uma entidade específica.
Serviço de infraestrutura: são usados pelo domínio para se comunicar com recursos externos.
As classes auxiliares tendem a conter trechos de código ou algoritmos que seriam reutilizados por várias entidades; portanto, não é possível entrar em entidades sem violar o princípio DRY. Eles provavelmente são os mais próximos dos Serviços de Domínio, pois eles cumprem o mesmo objetivo (externalizar a lógica de negócios das entidades), mas o fazem por diferentes motivos.