La cartographie par rapport à la couche de service, ou la position de la logique métier

Question

Je suis un produit et une collection de Payeurs. Les Contribuables peuvent payer pour le produit de trois façons différentes, soit, mais régler manuellement le pourcentage, en fonction du revenu des Payeurs ou la valeur des Payeurs respectives holdings.How le produit est versé est déterminé par un ENUM sur le produit.

Dans ma couche de persistance je suis arrivé trois classes, produits, Payeur et ProductManuallyPaid qui est un beaucoup à beaucoup de classe entre le produit et Payeur si le produit est payé par manuellement, en spécifiant le pourcentage de chaque payeur devra payer.

Comment dois-je mapper ce à la vue? Je voudrais avoir un nouveau beaucoup à beaucoup de classe (qui consisterait d'une référence au payeur, une référence au produit et le montant exact que payeur doit payer)?

Je suppose que le calcul doit être fait dans la couche de service, mais devrait la couche de service retourner une version ViewModel / DTO du produit / Payeur un nouveau nombre à beaucoup de classe attaché, ou doit-il être traité par la suite? si elle doit être traitée par la suite, si l'entité contient une liste de ce nouveau plusieurs à beaucoup de classe, mais être ignorées dans la couche de persistance?

Answer 1

DDD pourrait suggérer que vous devriez adopter une ligne de pensée qui se concentre d'abord et avant tout sur la conception du modèle d'objet plutôt que le modèle ER / données. Je vois que vous avez pensé à la façon dont le modèle de données devrait ressembler (avec le nombre à plusieurs etc table) mais peut-être vous devriez considérer comment le modèle d'objet pourrait regarder d'abord. Puis, comme ce modèle d'objet reflète le domaine (la logique métier, le comportement des entreprises), pensez à comment vous pourriez carte que le modèle d'objet à la base de données.

Par exemple, il serait plus logique de retourner un produit qui a une collection de paiements. Et chaque paiement ont un lien vers l'entité payeur. En fonction de votre conception qui ne peut avoir des copies Payeur de l'info Payeur vous voulez accéder ou peut-être ce lien sait comment charger l'entité complète Payeur les informations nécessaires / valeurs. En outre, chaque instance de payeur peut avoir une collection de paiements (même type de classe comme ci-dessus même?) Qui lien vers le produit.

Cette conception permet une meilleure utilisation des principes OO et décrit le domaine mieux que les façons une Might base de données relationnelle. De plus, ces objets peuvent être plus faciles à manipuler dans les services et les couches de l'interface utilisateur que leur structure d'objet natif vous fournit déjà logiquement les choses dont vous avez besoin. c'est à dire. un produit a les paiements qui ont le Payeur, etc ..

Je suis assez nouveau pour DDD me surprends à penser. Et avant que le terme DDD vous fait peur, jetez un oeil à cette version résumée de Evan livre . Il est une lumière lire et télécharger gratuitement. Il peut vous donner les pierres précieuses que vous avez cherché.