Je crée une logique commerciale dans l'application, mais je ne sais pas comment l'encapsuler, j'ai utilisé le motif de référentiel pour l'accès aux données, j'ai vu des projets qui utilisent DDD qui ont des classes Avec le suffixe "Service" et le suffixe "Manager", quelles sont chacune de ces classes supposées prendre soin de DDD?
3 Réponses :
Dans un scénario où vous avez décidé d'utiliser le modèle de modèle de domaine (clairement si vous souhaitez faire du DDD), la logique commerciale telle que les validations, les calculs et les règles commerciales fait définitivement une partie du modèle de domaine (vos objets commerciaux et leurs relations ).
Une bonne référence générale pourrait également vous donner Martin Fowlers Book "Motifs de l'architecture d'application d'entreprise" .
Ne soyez pas trop raccroché sur la nomenclature; En général, les services fournissent quelque chose à des classes afin de réduire le couplage et que le responsable est plus général toujours - pourrait être une classe qui garde une trace d'autres objets et / ou d'état.
Bien plus important pour une approche DDD consiste à modéliser le domaine. Cela dépend fortement de votre secteur (ou de l'industrie que votre application cible) et le type d'application que vous construisez. "Où encapsuler?" est la force motrice de base de ce processus, mais elle vient en grande partie à la création de représentations de classe d'entités réelles: employés, clients, fournisseurs, factures, transactions, citations, contrats, etc.
Les services et les gestionnaires peuvent aider à coller ces choses ensemble au moment de l'exécution et que la nomenclature aide à distinguer ces classes des choses qui encapsulent la logique de domaine.
Essayez d'être aussi précis que possible avec le nom. En règle générale, je serais Évitez le nom "Manager" , comme Sa signification est assez vague.
Les acteurs logiques d'entreprise typiques / noms seraient des validateurs, des règles, des fournisseurs, des superviseurs, des importateurs / exportateurs, des sérialisateurs, des processeurs (processus une transaction) et des référentiels (le dernier desquels vous avez déjà). Si une seule classe effectue plus d'une de ces fonctions, elle devrait probablement être divisée en sous-classes.
Vous avez posé la question: "Que prennent ces cours?" Et en effet, c'est le point. Le nom quelque choseManager ne vous dit rien. ordervalidator , d'autre part, vous indique très clairement ce que la classe fait, de même que CUSTMENTHISTORYEXPORTER . Les services sont un peu dans la zone grise; Si les services sont nuls d'une action passive, comme ShippingService , il est assez clair que le service traite, mais un meilleur nom pourrait être quelque chose comme shokingDispatcher . Vous avez l'idée, j'espère.