Réponses:
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. Ceci est généralement public, avec un sens commercial. Par exemple, une TicketingServiceinterface peut vous permettre de le faire buyTicket, sellTicketetc.
Une classe d'assistance a tendance à être cachée du client et est utilisée en interne pour fournir un travail sur plaque de chaudière qui n'a pas de signification de domaine métier. Par exemple, supposons que vous vouliez convertir une date en un horodatage afin de l'enregistrer dans votre magasin de données. Vous pourriez avoir une classe utilitaire appelée DateConvertoravec une convertDateToTimestampméthode qui effectue ce traitement.
Les services ne sont pas simplement étroitement liés aux DAO, c'est un modèle / terme d'utilisation plus large que la persistance
Les classes auxiliaires 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 d’utilitaire (par exemple, la conversion de date) et le faire correctement.
Ce n'est pas une définition scientifique, mais ma conception générale est qu'une classe de service a un contexte dans l'application alors que les assistants sont plus génériques et ne se soucient pas de l'application qu'ils aident.
Pour moi, je me fie à la définition d’Eric Evansservice qui ressemble à ceci:
En règle générale, dans un système bien conçu, la plupart des classes (dans le modèle de domaine) ont une responsabilité ou une fonction très claire, en ce sens qu'elles traitent d'une entité spécifique ou d'un ensemble d'entités du modèle.
c'est à dire
Lorsque vous avez des fonctionnalités qui n'appartiennent à aucune entité en particulier, il peut être difficile de trouver un endroit approprié pour s'asseoir. C'est à dire quelque chose qui encapsule un processus qui implique à la fois un AccountAND a Customer.
Donc, c’est là que a serviceintervient. C’est là que vous placez du code qui est dans le modèle de domaine mais qui n’appartient pas naturellement à une entité / composant ou à un autre.
Je pense helperà une sorte de classe de stratégie. Pour moi, c’est un endroit où mettre du code qui doit être réutilisé par diverses classes mais qui n’est peut-être pas tout à fait à la place de méthodes abstraites au sein de la hiérarchie des classes qui l’utilisent. Personnellement, je trouve le terme helperun 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.
Helper Class: 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 d'accéder à une ou plusieurs fonctionnalités, l'accès étant fourni à l'aide d'une interface spécifiée et exercé conformément aux contraintes et aux politiques définies dans la description de service."
Cette définition change légèrement en fonction de votre contexte. Cependant, le point critique est que le terme "service" désigne un niveau abstrait , le niveau d' architecture et la connaissance du domaine . La "classe d'assistance" est un modèle de conception (même s'il s'agit d'un anti-modèle car ils ont tendance à évoluer vers des classes de blob ou de dieux) faisant référence à une classe qui encapsule des opérations génériques (notez que ce niveau est inférieur et qu'il est connecté) connaissance de l' application / de la solution ). Je suis conscient du fait qu’il n’existe pratiquement aucun logiciel ne contenant aucune 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 font partie de la couche application et communiquent avec le domaine et la couche de données. Ils constituent l'interface par laquelle les systèmes externes / l'interface utilisateur interagissent avec le système DDD.
Service de domaine: il peut être utilisé par le domaine ou la couche d'application et contient 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 auxiliaires ont tendance à contenir des morceaux de code ou des algorithmes qui pourraient être réutilisés par plusieurs entités. Par conséquent, vous ne pouvez pas réellement accéder à des entités sans violer le principe DRY. Ils sont probablement plus proches des services de domaine, en ce sens qu'ils remplissent le même objectif (externaliser la logique métier des entités), mais ils le font pour des raisons différentes.