Diferença entre uma classe de serviço e uma classe auxiliar [fechada]

As linhas podem ficar um pouco borradas, mas eu vejo assim:

• Uma classe / interface de serviço fornece uma maneira de um cliente interagir com alguma funcionalidade no aplicativo. Isso é tipicamente público, com algum significado comercial. Por exemplo, uma interface TicketingService pode permitir que você use buyTicket , sellTicket e assim por diante.

• Uma classe auxiliar tende a ser ocultada do cliente e é usada internamente para fornecer algum trabalho de placa de caldeira que não tenha significado de domínio de negócios. Por exemplo, digamos que você queira converter uma data em um registro de data e hora para salvá-lo em seu datastore específico. Você pode ter uma classe de utilitário chamada DateConvertor com um método convertDateToTimestamp que realiza esse processamento.

Os serviços não são simplesmente acoplados aos DAOs, é um termo / padrão de uso mais amplo que a persistência

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 de utilidade (por exemplo, conversão de dados) e fazer isso bem.

Não é uma definição científica, mas minha opinião geral é que uma classe de serviço tem algum contexto dentro do aplicativo, enquanto os auxiliares são mais genéricos e não se importam com o aplicativo que estão ajudando.

Para mim, vou pelo Definição de Eric Evans de 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 na medida em que lidam com uma entidade específica ou um conjunto de entidades no modelo.

ou seja,

• Conta, Fábrica de Contas, Repositório de Contas, etc.
• Cliente, Fábrica do cliente, Repositório do cliente, etc.

Quando você tem uma funcionalidade que não pertence a nenhuma entidade específica, pode ser difícil encontrar um local correto para ela. Ou seja, algo que encapsula um processo que envolve tanto uma Account AND a Customer .

Então, é aí que entra um service . É onde você coloca o código que está no Modelo de Domínio, mas não pertence naturalmente a uma entidade / componente ou a outro.

Eu penso em um helper como um tipo de classe de estratégia. Para mim, é um lugar para colocar código que precisa ser reutilizado por várias classes, mas pode não se encaixar bem como métodos abstratos dentro da hierarquia das classes que o usam. Pessoalmente eu acho o termo helper um pouco vago e realmente não os tenho no meu modelo. Embora existam em bibliotecas que eu uso.

Classe de serviço: contenha a lógica de negócios.
Helper Class: esta classe é um tipo de componente reutilizável.

Você confundiu dois diretores não relacionados. Serviços e Classes Auxiliares não estão conectados. Especialmente o termo "Classe de Serviço" é enganador - eu acho que você está se referindo a um "Serviço" que está em um nível mais alto de abstração do que as classes. Um serviço é caracterizado através de

"a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description."

Esta 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 , o nível de arquitetura e conhecimento de domínio . A "Helper Class" é um padrão de design (mesmo que seja um antipadrão pois tendem a evoluir para blob's ou god classes) referindo-se a uma classe que encapsula operações genéricas (note que isto está em um nível inferior de abstração e está conectado ao aplicativo / conhecimento de solução ). Estou ciente do fato de que quase não existe nenhum 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 os sistemas externos / interface do usuário 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 infra-estrutura: 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 podem entrar em entidades sem violar o princípio DRY. Eles provavelmente estão mais próximos dos Serviços de Domínio, pois eles desempenham o mesmo propósito (externalizando a lógica de negócios das entidades), mas o fazem por motivos diferentes.