Brechen meine aggregierten Grenzen?

Ich habe bei mehreren Gelegenheiten einen ähnlichen Ansatz wie Ihr erstes Modell verwendet. Der einzige Haken bei diesem Ansatz besteht darin, dass Sie in Ihrer Domäne eine OganizationUser -Klasse erstellen müssen, um die Felder Rolle und Gekennzeichnet Ihrer Domäne zu behandeln. Das würde Sie in Ihrem Code mit so etwas zurücklassen.

* Wenn Sie häufig alle Benutzerorganisationen durchlaufen, möchten Sie wahrscheinlich die Entität Organisation zusammen mit OrganizationUser

Mit dem zweiten Entwurf, den Sie gesendet haben, sieht es so aus, als könnten Sie einen Benutzer zu den OrgUserDetails hinzufügen, ohne den Benutzer zu OrganizationUser hinzuzufügen. Das scheint nicht etwas zu sein, was ich von meiner Domain aus unterstützen möchte.

Dies ist eine typische Viele-zu-Viele-Beziehung. Und die Organization_Users-Tabellen sind die Bridge-Tabelle. Infact NHibernate und alle anderen ORM-Tools verfügen über eine integrierte Funktion zur Unterstützung der Bridge-Tabelle.

Diese Sache sollte auf Datenmodellierungsebene und nicht auf Anwendungsebene gelöst werden. Sie sollten Ihr Datenmodell analysieren und es wird empfohlen, Viele-zu-Viele-Beziehungen zu vermeiden (in dem Sinne, wenn es nicht die Notwendigkeit des Domänenmodells ist, sollten Sie versuchen, eine Viele-zu-Viele-Beziehung zu vermeiden).

Zunächst müssen Sie sicherstellen, dass eine Viele-zu-Viele-Beziehung im Datenmodell für die Zuordnung von Domänenelementen erforderlich ist. Sobald Sie dies getan haben, ist das in Ihrem Diagramm dargestellte Modell in Ordnung, um diese Beziehungen auf Anwendungsebene zuzuordnen

Die ersten Dinge in DDD sind:

• Vergessen Sie Ihr Datenbankschema (es gibt keine Datenbank!)
• Welche Aktionen werden Sie für diese Entitäten aus einer Domänenperspektive durchführen?

Ich denke, Ihr Modell ist in Ordnung. Normalerweise denke ich an Domain-Aggregat-Wurzeln, wenn ich überhaupt an sie denke, an das, was öffentlich sichtbar ist, nicht an die interne Implementierung. Bei Beziehungen denke ich daran, welche Entität "die Hosen" in der Beziehung trägt. Das heißt, ist es natürlicher, einen Benutzer zu einer Organisation hinzuzufügen oder eine Organisation einem Benutzer hinzuzufügen? In diesem Fall können beide sinnvoll sein, ein Benutzer tritt einer Organisation bei; Eine Organisation akzeptiert einen Benutzer für die Mitgliedschaft.

Wenn Ihre Domäne die Beziehung aus der Sicht des Benutzers sieht, können Sie die Methoden zum Beibehalten (Hinzufügen, Entfernen usw.) der Beziehung für den Benutzer festlegen und eine schreibgeschützte Sammlung für die Organisation verfügbar machen.

Als Reaktion auf Ihr zweites Design (es wäre besser gewesen, wenn Sie die ursprüngliche Frage bearbeitet hätten): Ich mag es überhaupt nicht. Ihr ursprüngliches Design ist in Ordnung. Ich würde die Datenbank beim Entwurf Ihrer Klassen nicht unbedingt ignorieren, ein gutes Design sollte die Domäne genau modellieren und in einer relationalen Datenbank einfach zu implementieren sein. Manchmal muss man in beide Richtungen Kompromisse eingehen, um den Sweet Spot zu treffen. Es gibt keine Haftstrafe dafür, dass man die Gesamtgrenzen überschreitet. : -)

Mein Verständnis ist:

Ein Benutzer kann zu 0-zu-viele-Organisationen gehören. UND Eine Organisation besteht aus 0-zu-vielen Benutzern.

Stimmt beides? Wenn dem so ist, klingt das für mich wie ein Viele-zu-Viele.

In einer Many-to-Many braucht man ziemlich genau ein beziehungsähnliches Objekt, um diese Lücke zu überbrücken. Das Problem ist, es gibt keine user_organization in der Domäne.

Das lässt mich denken, dass Sie user_organisation nicht als Teil Ihrer Domain an sich haben sollten. Es fühlt sich an wie ein Implementierungsdetail.

Auf der anderen Seite macht es vielleicht in Ihrer Domain Sinn, einen Roster zu haben, der die Benutzer in einer Organisation hält und deren Rolle und andere spezifische Informationen zu dieser Beziehung speichert.

Vielen Dank für Ihre Antworten. Sie waren sehr hilfreich.

Während ich ein wenig mehr an mein Modell dachte, skizzierte ich etwas Neues, von dem ich denke, dass es besser wäre.

Alternativtext http://i26.tinypic.com/ic0pw4.png

Mein Gedanke war folgendes:

1. Wenn sich ein Benutzer bei der Site anmeldet, findet das System seinen Account und gibt dann eine Liste der Organisationen zurück, von denen sie getrennt sind, und diese Informationen werden vom Objekt user_organizations abgerufen.

2. Wenn ein Benutzer auf eine der Organisationen klickt, von denen er getrennt ist, leitet er sie an das Steuerungsfeld der Organisation weiter.

3. Die ausgewählte Organisation sucht dann in den org_user_details nach der Rolle des Benutzers, um zu erfahren, welchen Zugriff der Benutzer auf das Organisationssteuerungsfeld haben sollte.

Macht das Sinn? :)

Ich denke, das wäre in einem Modell gut, aber ich habe einige Zweifel an der DB-Implementierung. Ich weiß, ich sollte mich nicht einmal darum kümmern, aber ich kann meine schlechte Angewohnheit noch nicht brechen! Sie können sehen, dass im Objekt user_organizations und im Objekt org_user_details doppelte Daten vorhanden sind. Ich bin kein DB-Profi, aber ist das ein schlechtes DB-Design? Sollte ich stattdessen die Daten von user_organizations und org_user_details in eine Tabelle wie die in meinem ersten Beitrag kombinieren und einfach NHibernate sagen, dass der Benutzer es als eine Viele-zu-Viele-Beziehung betrachtet und die Organisation es als eine Eins-zu-Viele-Beziehung betrachtet ? Das klingt, als würde ich das System austricksen. Tut mir leid, wenn ich wirklich verwirrt darüber zu sein schien.

Was sind deine Gedanken dazu? Überlege ich das? : P