Domaine Driven Desgin - Problèmes avec un exemple réel

Question

Je veux plonger dans "DDD" et je suis confronté à quelques problèmes dans la façon d'implémenter explicitement un cas le "DDD" -way. Voici une partie de mon modèle de domaine. Ce que je veux faire est la suivante: Disons que j'ai un technicien conduisant à certains clients. Il divise ses visites en plusieurs tours un jour. Ainsi, par exemple, un jour, il fait un tour le matin avec 3 visites, et une dans l'après-midi avec 2 visites. À chaque visite, il prend des activités, une ou plusieurs, qui peuvent aussi avoir des sous-activités.

Le technicien est payé par un accord de paiement qui a position pour chaque activité. L'accord peut changer au fil du temps, il a donc quelques dates pour déterminer quand il est actif. Pour mapper l'activité à une position d'activité, elle a un ID abstrait qui sera traduit en une ActivitiPosition en fonction de PaymentAgreement.

Maintenant, le technicien veut réserver un jour et créer une facture ou ajouter une facture à une facture existante. Pour créer une InvoicePosition, j'ai besoin d'informations sur le Tour (kilomètres parcourus), la visite (l'accord de paiement peut varier en fonction du client), les activités et le PaymentAgreement qui est valide à ce jour.

Il y a une certaine validation nécessaire avant de réserver un jour et il y a quelques cas particuliers dans la logique commerciale que je n'élaborerai pas plus loin.

Ma question est maintenant: Qui est responsable de la création de quoi dans le "DDD" -way? Devrais-je créer une méthode d'usine dans InvoicePosition qui prend le km, la visite, l'activité et une source de PaymentAgreement (pour déterminer le réel, car l'accès à un dépôt ne devrait pas être fait dans les entités, non?)? Ou devrais-je transmettre toutes les informations à l'activité pour créer une InvoicePosition (ou une liste de InvoicePositions)? Ou devrait-il y avoir un objet supplémentaire (une sorte de convertisseur?)?

La transmission d'une "source" (qui serait un référentiel) de PaymentAgreements à la fonction de conversion serait-elle un bon choix? Y a-t-il une solution alternative?

Et une question supplémentaire aux développeurs Java/CDI: Comme les entités ne sont pas dans un contexte CDI, quelle est la manière précise de déclencher des événements CDI en tant qu'événements de domaine? C'est un projet JavaEE. Est-ce que toutes les entités devraient être gérées par CDI? Ou est-ce que je dois injecter manuellement un CDI eventbus dans chaque entité (je ne l'espère pas, car cela semble être un hack de drité plutôt qu'une solution propre)?

Answer 1

Vous adopterez probablement deux approches différentes. Vous aurez un tas d'entrées provenant du monde réel, des représentations de ce qui s'est passé en dehors du contrôle du modèle que vous mettez en cache et que vous préservez. Cette partie est la plupart du temps juste la collecte de données, vous n'avez pas un modèle de domaine riche ici, car il n'y a pas d'invariants à protéger. Ensuite, en plus de cela, vous aurez un modèle de domaine qui, en prenant en compte ces échantillons collectés, calcule vos positions de facturation. C'est votre modèle riche, et ses positions seront basées sur les entrées qu'il a reçues. Donc, il y a une certaine quantité d'orchestration à faire (Bob a rapporté cette information de ce travail, nous l'écrivons, et maintenant nous passons cette information au modèle de domaine pour être incorporé dans les positions).