Je voudrais savoir ce qui différencie une classe de service d'une classe utilitaire ou d'une classe d'assistance? Une classe uniquement avec des méthodes sous-jacentes appelle le dao est un service? L'utilisation des classes d'assistance ne viole-t-elle pas SRP?
Les lignes peuvent être un peu floues, mais je le vois de cette façon:
Une classe/interface de service permet à un client d'interagir avec certaines fonctionnalités de l'application. C'est généralement public, avec une signification commerciale. Par exemple, une interface TicketingService
peut vous permettre de buyTicket
, sellTicket
et ainsi de suite.
Une classe d'assistance a tendance à être cachée au client et est utilisée en interne pour fournir un travail de plaque de chaudière qui n'a aucune signification dans le domaine commercial. Par exemple, supposons que vous vouliez convertir une date en horodatage afin de l'enregistrer dans votre magasin de données particulier. Vous pouvez avoir une classe utilitaire appelée DateConvertor
avec une méthode convertDateToTimestamp
qui effectue ce traitement.
Les services ne sont pas simplement étroitement liés aux DAO, c'est un terme/modèle d'utilisation plus large que la persistance
Les classes d'assistance ne violent pas SRP si elles sont codées conformément à ce principe. Autrement dit, chaque méthode doit faire une chose et une chose bien, la classe doit effectuer un type d'aide utilitaire, (par exemple la conversion de date) et bien le faire.
Pas une définition scientifique, mais mon opinion générale est qu'une classe de service a un certain contexte dans l'application, tandis que les assistants sont plus génériques et ne se soucient pas de l'application qu'ils aident.
Pour moi, je vais par le définition d'Eric Evans de service
qui est quelque chose comme ceci:
Généralement, dans un système bien conçu, la plupart des classes (dans le modèle de domaine) ont une responsabilité ou une fonction assez claire en ce qu'elles traitent d'une entité ou d'un ensemble d'entités spécifique dans le modèle.
c'est à dire.
Lorsque vous avez des fonctionnalités qui n'appartiennent à aucune entité particulière, il peut être difficile de trouver un endroit correct pour s'asseoir. C'est-à-dire quelque chose qui encapsule un processus qui implique à la fois un Account
ET un Customer
.
C'est là qu'intervient un service
. C'est là que vous mettez du code qui est dans le modèle de domaine mais qui n'appartient pas naturellement à une entité/un composant ou un autre.
Je pense à un helper
comme une sorte de classe de stratégie. Pour moi, c'est un endroit pour mettre du code qui doit être réutilisé par diverses classes mais qui pourrait ne pas être tout à fait approprié en tant que méthode abstraite dans la hiérarchie des classes qui l'utilisent. Personnellement, je trouve le terme helper
un peu vague et je ne les ai pas vraiment dans mon modèle. Bien qu'ils existent dans les bibliothèques que j'utilise.
Classe de service: Contient la logique métier.
Classe d'assistance: cette classe est un type de composant réutilisable.
Vous avez confondu deux principes non liés. Les services et les classes d'assistance ne sont pas connectés. En particulier, le terme "classe de service" est trompeur - je pense que vous faites référence à un "service" qui est à un niveau d'abstraction plus élevé que les classes. Un service se caractérise par
"un mécanisme permettant l'accès à une ou plusieurs capacités, où l'accès est fourni à l'aide d'une interface prescrite et est exercé conformément aux contraintes et aux politiques spécifiées par la description du service."
Cette définition change légèrement en fonction de votre contexte. Cependant, le point critique est que le terme "service" est sur un niveau abstrait, le niveau de architecture et connaissance du domaine. La "classe d'assistance" est un modèle de conception (même si c'est un anti-modèle car ils ont tendance à évoluer vers des classes de blob ou de dieu) se référant à une classe qui encapsule des opérations génériques (notez que c'est sur un niveau inférieur de abstraction et est connecté à connaissance application/solution). Je suis conscient du fait qu'il n'existe pratiquement aucun logiciel ne contenant aucun type de classe d'assistance, mais c'est quand même une mauvaise pratique.
Il faut se méfier des multiples définitions de "service" dans DDD:
Service d'application: ils se trouvent dans la couche application et communiquent avec le domaine et la couche de données, ils sont l'interface par laquelle les systèmes/UI externes interagissent avec le système DDD.
Service de domaine: il peut être utilisé par le domaine ou la couche d'application et contenir une logique métier qui ne s'intègre pas parfaitement dans une entité particulière.
Service d'infrastructure: ils sont utilisés par le domaine pour communiquer avec des ressources externes.
Les classes d'assistance ont tendance à contenir des morceaux de code ou des algorithmes qui seraient réutilisés par plusieurs entités, donc ne peuvent pas vraiment entrer dans des entités sans violer le principe DRY. Ils sont probablement les plus proches des services de domaine, dans qu'ils trient remplissent le même objectif (externaliser la logique métier des entités) mais ils le font pour des raisons différentes.