In welche Richtung, um die Assoziation im Domänenmodell zu machen

Question

Gibt es eine Faustregel, in welche Richtung die Zuordnung beim Entwurf des Domänenmodells zu machen?

Zum Beispiel haben wir Produkte im Lager. Der Bestandsstatus eines Produkts ist eine ziemlich komplexe Datenstruktur, die Aufzählungen mehrerer Varianten des Produkts enthält, die sich entweder im Lager befinden, nicht auf Lager sind oder buchbar sind. Daher machen wir ein separates Objekt des Lagerstatus, der dem Produkt zugeordnet ist. Die Frage ist nun, ob das Produktobjekt einen Verweis auf seinen Bestandsstatus haben soll oder ob der Bestandsstatus einen Verweis auf ein bestimmtes Produkt hat..

Erste Lösung fühlt sich an, es ist nicht die wirkliche Sorge des Produkts zu wissen, es ist Lagerbestand. Produkt ist nur ein Produkt, und vielleicht sollten wir es in einem anderen Kontext manipulieren, in dem die Lagerung keine Rolle spielt. Auf der anderen Seite fühlt sich der Lagerbestand, der eine Wurzel ist, unangenehm an, wenn wir über Lager nachdenken, zuerst denken wir über ein Produkt, das in der Aktie ist.

Wie zu entscheiden, welche Entität als eine Wurzel für die Zuordnung fungiert?

Answer 1

Sie gehen davon aus, dass beide Konzepte eng miteinander verbunden sind, dh sie gehören zum selben begrenzten Kontext. Das bedeutet, dass beide Modelle voneinander abhängig werden - was Sie vielleicht nicht wollen, weil es Komplexität verursacht, die Sie vielleicht nicht wollen. Schließlich haben Sie es selbst erwähnt: "Es ist nicht die wirkliche Sorge des Produkts, zu wissen, dass es sich um einen Lagerbestand handelt". Warum also eine Beziehung hinzufügen?

Sie könnten sie als zwei separate beschränkte Kontexte betrachten - keine direkte Beziehung zwischen ihnen, außer für die Produkt-ID, die die beiden Konzepte verbindet.

Answer 2

Navigierbarkeit ist etwas, was Sie einfach vernachlässigen sollten, da es etwas rein Künstliches ist. Wenn zwei Dinge miteinander verwandt sind, wissen sie voneinander. Actio et reactio. Schwere. Liebe. Versuche, etwas zu finden, das nur in eine Richtung funktioniert. Erpressung. Spionspiegel.

Die Einführung der Schiffbarkeit hat in der Tat nur Sinn in der Implementierungsphase. Sie versuchen, Dinge zu entkoppeln, um Abhängigkeiten zu reduzieren, jetzt für immer. Und was Sie hier tun, ist, der Navigation Rollennamen zuzuordnen. Was wiederum die Pfeile überflüssig macht.

TL; DR; Verwenden Sie einfach keine Pfeile in der UML-Modellierung. Lass sie für die Powerpoint League.

Answer 3

Die erste Lösung fühlt sich an wie, es ist nicht die wirkliche Sorge des Produkts, wenn es weiß, dass es sich um einen Lagerzustand handelt. Produkt ist nur ein Produkt, und vielleicht sollten wir es in einem anderen Kontext manipulieren, in dem die Lagerung keine Rolle spielt. Auf der anderen Seite fühlt sich der Lagerbestand, der eine Wurzel ist, unangenehm an, wenn wir über Lager nachdenken, denken wir zuerst darüber nach, dass ein Produkt im Lager ist.

Wenn wir über Einkaufswagen nachdenken, denken wir über Produkte im Einkaufswagen nach. In den meisten Fällen ist es jedoch sinnvoll, Cart-Artikel zu modellieren, indem Sie sich auf das Produkt beziehen.

Meine Vermutung wäre, dass Sie mehr über Stock denken müssen, und insbesondere über seinen Lebenszyklus; Wie eng sind die Lebenszeiten der beiden unterschiedlichen Ideen gekoppelt? Wenn Sie eine Situation haben, in der eine einzelne Product eine Beziehung zu zwei verschiedenen Stocks hat (eine in der Vergangenheit, eine in der Gegenwart; eine an dieser Stelle, eine andere an dieser Stelle), dann ist das Speichern dieser Beziehung im Produkt nicht richtig.