2010-06-23 24 views
0

Je suis en train de déterminer les entités, les objets de valeur et les agrégats dans un système. Dire que les entités suivantes ont été identifiées:Agrégats et objets de valeur: Supprimer?

Client, customerEmail, E-mail, CustomerAddress, Adresse, AddressType

où les clients -> Les e-mails est une relation plusieurs à plusieurs, comme clients -> Adresses (avec un type d'adresse). Ces relations sont représentées par les objets de relation CustomerAddress et CustomerEmail.

Au début, je pensais que c'était simple:

Entités: clients, customerEmail, CustomerAddress Objets de valeur: E-mail, Adresse, AddressType

avec un client étant la racine globale pour un ensemble contenant toutes les entités et VO ci-dessus. Le problème que je rencontre (et je ne connais que les concepts de regroupement à mesure que je vais de l'avant) Supposons que vous ayez une entité fournisseur qui reflète l'agrégat client ci-dessus, en utilisant les mêmes objets de valeur Adresse et Courriel. Dans ce cas, lorsqu'un client est supprimé, l'adresse et le courrier électronique ne doivent pas être supprimés, car un fournisseur ou même un autre client peut toujours les référencer. J'ai vu beaucoup de documentation qui suggère quand un agrégat est supprimé, tout ce qui est dans la limite globale est supprimé en une fois. Ai-je raison de supposer que cela ne s'applique pas aux objets de valeur dans l'ensemble (c'est-à-dire qu'ils sont immuables ... si nous avions un objet couleur vert dans un agrégat de véhicule ... vous ne supprimeriez pas la couleur juste parce qu'une voiture a été supprimé) ou l'adresse électronique et l'adresse doivent-elles être propres (et agrégées) car deux adresses, même si elles ont les mêmes attributs, sont des identités distinctes (l'une est une adresse du fournisseur, l'autre une adresse du client?) Enfin, s'il s'agit bien d'objets de valeur, comment traiter le cas où ils devraient être supprimés (aucun fournisseur ou client ne continue de référencer une adresse) si les VO ne peuvent être traités que par leur racine agrégée?

Cheers,

Steve

Répondre

2

Vous pensez à votre domaine dans thermies de votre base de données. Ceci n'est pas recommandé.

Entité fournisseur qui reflète le plus haut total Client

Cela vous suggère manque un concept dans votre domaine. Que signifie cette "mise en miroir" pour votre expert de domaine? S'il existe effectivement une relation entre eux, elle devrait être explicitement modélisée.

Vous dites que "Customers -> Emails est une relation de plusieurs à plusieurs". Est-ce significatif pour votre domaine qu'un e-mail est partagé par plusieurs clients? Si oui encore, il vous manque probablement un concept. Vérifiez ce que votre expert de domaine a à dire à propos de cette relation. Si ce n'est pas vraiment beaucoup à beaucoup mais un à plusieurs, peut-être que l'email est un objet de valeur que l'entité cliente "possède". Maintenant, si le client possède le courriel ou l'adresse, vous pouvez le supprimer (ou agir sur lui) sans aucune restriction. L'une des choses les plus difficiles à propos de DDD est que vous finissez toujours par essayer de partager des entités entre des agrégats. Ne pas. Vous vaincre le point de trou d'un agrégat - la limite de cohérence.Au lieu de cela, avec l'aide de votre expert de domaine, identifiez les concepts manquants qui clarifieront les frontières entre les RA. Je sais que tout cela semble abstrait (j'ai déjà posé des questions comme ça dans le passé) mais la vérité est que seul votre expert de domaine peut vous aider à mieux modéliser le domaine.

Et en dernier conseil - re (-re X 100) en lisant habituellement le livre d'Eric Evans :)