Wo wird ein gemeinsames Wertobjekt zwischen zwei beschränkten Kontexten eingefügt?

Question

Ich versuche, das domänenorientierte Design in einem kleinen Projekt anwenden Ich möchte die Authentifizierung der Rest der Benutzer Logik trennen, Ich benutze ein Wertobjekt für die ID (userID) am Anfang habe ich die Benutzer-ID in der gleichen Ebene (Paket) der Benutzer, aber ich erkenne, wenn ich begrenzten Kontext für die Authentifizierung und Benutzer trennen, teilen sie ein gemeinsames Wertobjekt für die Benutzer-ID, so meine Frage ist, wo ich den gemeinsamen Wert setzen oder teilen Objekte? ist richtig, wenn ich ein Paket namens Commons erstellt habe?

Answer 1

Pakete, die "Common" genannt werden, beziehen sich normalerweise auf wiederverwendbare Konzepte, die Sie in Ihren Projekten verwenden, sodass Sie sie nicht in jedem Projekt codieren müssen. Dort ist es üblich, abstrakte Basisobjekte und Schnittstellen für Entitäten, Wertobjekte usw. zu setzen.

Aber es geht nicht um userId. Was Sie sagen, ist, userID in ein "shared kernel" -Modell zu setzen. Es ist eine Option, aber normalerweise wird es nicht empfohlen.

Aus meiner Sicht:

Die Auth BC hat die Konzepte ID, Login, Passwort, Rolle, etc.

Der Benutzer BC hat Begriffe wie Name, Vorname, Adresse, Alter usw., aber es muss auch die ID haben, die es von Auth BC erhält.

Von dem, was ich weiß, haben Sie 2 Möglichkeiten:

(1) Authentifizierung BC ist ein gemeinsamer Kernel. So ist userId freigegeben und gehört auch zu Benutzer BC.

(2) Authentifizierung BC ist ein generisches BC. Daher müssen Sie den Benutzer BC mit dem Auth BC integrieren, um die ID daraus zu erhalten.

Answer 2

Es wird empfohlen, keine Modelle zwischen beschränkten Kontexten zu teilen, Sie können jedoch IDs und sogar einfache Value-Objekte (wie Money) teilen.

Die allgemeine Regel ist, dass Sie alles teilen kann, die oder dass Änderungen sehr selten und IDs selten Struktur (hier Unveränderlichkeit bezieht sich auf den Quellcode und Wert Unveränderlichkeit) ändern unveränderlich ist.