Verstößt die Domain-Einheit gegen das Prinzip der Einzelverantwortung?

Die einzige Verantwortung (Grund für eine Änderung) eines Unternehmens sollte darin bestehen, sich eindeutig zu identifizieren, dh seine Verantwortung muss auffindbar sein.

Eric Evans DDD-Buch, pg. 93

Die Hauptaufgabe der Unternehmen besteht darin, Kontinuität herzustellen, damit das Verhalten klar und vorhersehbar ist. Sie tun dies am besten, wenn sie in Reserve gehalten werden. Anstatt sich auf die Attribute oder sogar das Verhalten zu konzentrieren, reduzieren Sie die Definition des Entity-Objekts auf die wesentlichsten Merkmale, insbesondere auf die, die es identifizieren oder üblicherweise zum Finden oder Übereinstimmen verwendet werden. Fügen Sie nur das Verhalten hinzu, das für das Konzept und die Attribute, die für dieses Verhalten erforderlich sind, wesentlich ist.

Darüber hinaus sollten Sie Verhalten und Attribute in anderen Objekten entfernen, die mit der Hauptentität verknüpft sind. Über Identitätsprobleme hinaus erfüllen Entitäten ihre Verantwortlichkeiten in der Regel durch die Koordination der Operationen von Objekten, deren Eigentümer sie sind.

1.

... reduzieren Sie die Definition des ENTITY-Objekts auf die wesentlichsten Merkmale, insbesondere auf diejenigen, die es identifizieren oder üblicherweise zum Finden oder Abgleichen verwendet werden. Füge nur das Verhalten hinzu, das für das Konzept wesentlich ist ...

Sobald einer Entität eine eindeutige ID zugewiesen wurde , wird ihre Identität festgestellt. Daher würde ich davon ausgehen, dass eine solche Entität kein Verhalten benötigt, um ihre Identität beizubehalten oder sich selbst zu identifizieren . Daher verstehe ich nicht, auf welche Art von Verhalten sich der Autor bezieht (abgesehen von findund match Operationen ) mit " Verhalten, das für das Konzept wesentlich ist "?

2.

... reduzieren Sie die Definition des ENTITY-Objekts auf die wesentlichsten Merkmale, insbesondere auf diejenigen, die es identifizieren oder üblicherweise zum Finden oder Abgleichen verwendet werden. ... Versuchen Sie darüber hinaus, Verhalten und Attribute in anderen Objekten zu entfernen, die mit dem ENTITY-Kern verknüpft sind.

Jedes Verhalten, das nicht dazu beiträgt, die Entität zu identifizieren, wird dennoch als eigenständiges Merkmal dieser Entität charakterisiert (dh das Bellen ist für Hunde, das Fliegen für Flugzeuge und das Legen von Eiern für Vögel). .), sollte in andere Objekte eingefügt werden, die dieser Entität zugeordnet sind (Beispiel: Wir sollten ein Objekt, das einer Entität mit Hund zugeordnet ist, mit Bellen versehen)?

3.

Versuchen Sie darüber hinaus, Verhalten und Attribute in anderen Objekten zu entfernen, die der ENTITY zugeordnet sind.

a) MyEntityDelegierten Verantwortung A_respund B_respauf Objekte aund bsind.

Obwohl die meisten von A_resp und B_respArbeit getan ist aund bFällen werden Kunden noch bedient A_respund B_respdurch MyEntity, was bedeutet , dass aus der Sicht des Kunden die beiden Aufgaben gehören MyEntity. So nicht , dass Mittel MyEntityauch hat A_respund B_respVerantwortlichkeiten und als solche verletzt SRP ?

b) Auch wenn wir davon ausgehen, dass A_respund B_respgehören nicht MyEntity, MyEntityhat die AB_respKoordinierung der Operationen von Objekten aund b. Verstößt es also nicht MyEntitygegen SRP, da es mindestens zwei Verantwortlichkeiten hat - sich selbst und auch eindeutig zu identifizieren AB_resp?

class MyEntity
{
    private A a = ...
    private B b = ...


    public A GetA()
    { ... }

    public B GetB()
    { ... }

    /* coordinates operations of objects a and b */
    public int AworkB()
    { ... }
}

/* A encapsulates a single responsibility resp_A*/
/* A is value object */
class A
{ ... }

/* B encapsulates a single responsibility resp_B*/
/* B is value object */
class B
{ ... }

AKTUALISIEREN:

1.

Verhalten bezieht sich in diesem Zusammenhang auf semantisches Verhalten. Beispielsweise hat eine Eigenschaft für eine Klasse (dh ein Attribut für ein Domänenobjekt), mit der sie eindeutig identifiziert wird, ein Verhalten. Dies wird zwar nicht direkt im Code dargestellt. Das erwartete Verhalten besteht darin, dass für diese Eigenschaft keine doppelten Werte vorhanden sind.

Im Code müssten wir also so gut wie nie ein Verhalten (dh eine Operation) implementieren, das die Identität der Entität aufrechterhält, da ein solches Verhalten, wie Sie erklärt haben, nur als Konzept in einem Domänenmodell vorhanden ist (in Form eines ID-Attributs von eine Entität), aber wenn wir dieses ID-Attribut in Code übersetzen, geht ein Teil seiner Semantik verloren (dh der Teil, der implizit sicherstellt, dass der ID-Wert eindeutig ist, geht verloren)?

2.

Darüber hinaus hat eine Eigenschaft wie Age keinen Kontext außerhalb einer Personenentität und als solche macht es keinen Sinn, sich in ein anderes Objekt zu bewegen ... Diese Informationen könnten jedoch leicht an einem anderen Ort gespeichert werden, an dem die eindeutige Kennung, also die verwirrender Verweis auf das Verhalten. Alter könnte ein faul geladener Wert sein.

a) Wenn die AgeEigenschaft faul geladen ist, können wir es ein Verhalten nennen, obwohl semantisch Agenur ein Attribut ist?

3.

Sie können leicht spezifische Vorgänge für die Adresse ausführen, z. B. die Überprüfung, ob es sich um eine gültige Adresse handelt. Vielleicht wissen Sie das zur Entwurfszeit nicht, aber dieses ganze Konzept besteht darin, Objekte in ihre kleinsten Teile zu zerlegen

Ich stimme zwar zu, dass wir durch einen Umzug den Kontext verlieren würden Age in ein anderes Objekt den Kontext würden, aber der Kontext würde nicht verloren gehen, wenn wir die DateOfBirthEigenschaft in ein anderes Objekt verschieben würden, aber normalerweise verschieben wir sie nicht.

Was ist der Hauptgrund, warum wir Addressin ein anderes Objekt ziehen würden, aber nicht DateOfBirth? Da DateOfBirthist mehr intrinsisch zuPerson Entität oder weil es weniger Chancen gibt, dass wir irgendwo in der Zukunft Operationen definieren müssen, die spezifisch für die Entität sind DateOfBirth?

4. Ich muss sagen , ich weiß noch nicht , ob MyEntityauch hat A_respund B_respVerantwortlichkeiten und warum MyEntityauch haben AB_respnicht eine Verletzung angesehen wird SRP

EULERFX

1)

Die Verhaltensweisen, auf die sich der Autor bezieht, sind Verhaltensweisen, die der Entität zugeordnet sind. Dies sind die Verhaltensweisen, die den Status der Entität ändern

a) Wenn ich Sie richtig verstehe, sagen Sie, dass eine Entität nur solche Verhaltensweisen enthalten sollte, die ihre Attribute (dh ihre Zustand ) ?

b) Und was ist mit den Verhaltensweisen , die nicht notwendigerweise den ändern Zustand des Unternehmens , sind aber nach wie vor als eine betrachtet intrinsische Eigenschaft dieses Unternehmens (Beispiel: Bellen wären intrinsische Charakteristik einer DogEinheit, auch wenn es nicht ändern Hundezustand )? Sollten wir diese Verhaltensweisen in eine Entität einbeziehen oder sollten sie auf andere Objekte verschoben werden?

2)

In Bezug auf das Verschieben von Verhalten auf andere Objekte bezieht sich der Autor speziell auf Wertobjekte.

Obwohl mein Zitat es nicht enthält, erwähnt der Autor im selben Absatz, dass in einigen Fällen Verhalten (und Attribute ) auch in andere Entitäten verschoben werden (obwohl ich die Vorteile des Verschiebens von Verhalten in VOs verstehe).

3) Unter der Annahme, dass MyEntity(siehe Frage 3 in meinem ursprünglichen Beitrag) SRP nicht verletzt, würden wir sagen, dass eine Verantwortung von MyEntityunter anderem auch besteht aus:

ein. A_resp + B_resp + AB_resp ( AB_respkoordiniert Objekte aund b)

oder

b. AB_resp + Delegieren von A_respund B_respan Objekte ( aund b), die mit verknüpft sindMyEntity ?

4) Eric Evans DDD-Buch, pg. 94

Die Kunden-ID ist die einzige Kennung der ENTITÄT des Kunden (Abbildung 5.5). Die Telefonnummer und die Adresse werden jedoch häufig verwendet, um einen Kunden zu finden oder zu finden. Der Name definiert nicht die Identität einer Person, wird jedoch häufig als Teil der Mittel zur Bestimmung dieser Identität verwendet.

In diesem Beispiel wurden die Telefon- und Adressattribute in "Kunde" verschoben. Bei einem realen Projekt hängt diese Auswahl jedoch davon ab, wie die Kunden der Domain normalerweise abgeglichen oder unterschieden werden. Wenn ein Kunde beispielsweise viele Kontakttelefonnummern für verschiedene Zwecke hat, ist die Telefonnummer nicht mit der Identität verknüpft und sollte beim Vertriebskontakt verbleiben.

ein)

Die Kunden-ID ist die einzige Kennung der ENTITÄT des Kunden (Abbildung 5.5). Die Telefonnummer und die Adresse werden jedoch häufig verwendet, um einen Kunden zu finden oder zu finden. Der Name definiert nicht die Identität einer Person, wird jedoch häufig als Teil der Mittel zur Bestimmung dieser Identität verwendet.

Das Anführungszeichen gibt an, dass nur mit der Identität verknüpfte Attribute in einer Entität verbleiben sollen . Ich gehe davon aus, dass author bedeutet, dass die Entität nur die Attribute enthalten soll , die häufig zum Finden oder Abgleichen dieser Entität verwendet werden , während ALLE anderen Attribute verschoben werden sollen.

b) Aber wie / wo sollen andere Attribute verschoben werden? Zum Beispiel (hier wird davon ausgegangen, dass das Adressattribut nicht zum Finden oder Übereinstimmen verwendet wird Customer und daher das Adressattribut verschoben werden soll Customer):

Wenn wir anstelle von Customer.Address(vom Typ string) eine Eigenschaft Customer.Addressvom Typ erstellen Address, haben wir das Adressattribut in ein zugehöriges VO-Objekt verschoben (das vom Typ ist Address), oder würden wir sagen, dass dieses Customernoch das Adressattribut enthält ?

c)

In diesem Beispiel wurden die Telefon- und Adressattribute in "Kunde" verschoben. Bei einem realen Projekt hängt diese Auswahl jedoch davon ab, wie die Kunden der Domain normalerweise abgeglichen oder unterschieden werden. Wenn ein Kunde beispielsweise viele Kontakttelefonnummern für verschiedene Zwecke hat, ist die Telefonnummer nicht mit der Identität verknüpft und sollte beim Vertriebskontakt verbleiben.

Ist der Autor hier nicht falsch, denn wenn wir jede der vielen Kontakttelefonnummern annehmen , Customerdie nur zu dieser bestimmten gehören Customer, dann würde ich sagen, dass diese Telefonnummern genauso mit der Identität assoziiert sind, wie wenn sie Customernur eine Telefonnummer hatten ?

5)

Der Grund, warum der Autor vorschlägt, die Entität zu reduzieren, ist, dass beim erstmaligen Erstellen einer Customer-Entität die Tendenz besteht, sie mit allen Attributen zu füllen, von denen man annimmt, dass sie einem Kunden zugeordnet sind. Dies ist ein datenzentrierter Ansatz, der Verhaltensweisen übersieht, die letztendlich zu einem anämischen Domänenmodell führen.

Ich dachte jedoch, ein anämisches Domänenmodell resultiert aus dem Verschieben von Verhalten aus einer Entität heraus , während Ihr Beispiel eine Entität mit vielen Attributen auffüllt , was Customerzu zu viel Verhalten führen würde (da wir wahrscheinlich auch in Customerdie Verhaltensweisen welche einbeziehen würden) diese zusätzlichen Attribute modifizieren ) und damit SRP verletzen?

Vielen Dank

Verhalten bezieht sich in diesem Zusammenhang auf semantisches Verhalten. Beispielsweise hat eine Eigenschaft für eine Klasse (dh ein Attribut für ein Domänenobjekt), mit der sie eindeutig identifiziert wird, ein Verhalten. Dies wird zwar nicht direkt im Code dargestellt. Das erwartete Verhalten besteht darin, dass für diese Eigenschaft keine doppelten Werte vorhanden sind. Etwas wie eine Adresse, die möglicherweise eine eigene Identität hat, aber außerhalb des Kontexts einer Personenentität nicht existiert, sollte dennoch in das eigene Objekt verschoben werden. Auf diese Weise wird die Entität zu einer aggregierten Wurzel befördert.

Darüber hinaus hat eine Eigenschaft wie Age keinen Kontext außerhalb einer Personenentität und als solche macht es keinen Sinn, sich in ein anderes Objekt zu bewegen. Der Kontext würde verloren gehen, und daher können Sie sicher feststellen, dass es sich um einen Wert handelt, der für die Personenentität von wesentlicher Bedeutung ist. Sie konnten den Wert sonst nicht finden. Diese Informationen könnten jedoch leicht an einem anderen Ort als der eindeutigen Kennung gespeichert werden, weshalb die Bezugnahme auf das Verhalten verwirrend ist . Alter könnte ein faul geladener Wert sein.

Also, um deine Frage zu beantworten. Nein, es verstößt nicht gegen das Prinzip der einheitlichen Verantwortung. Es wird ausdrücklich darauf hingewiesen, dass eine Person nur personenbezogene Inhalte haben sollte, und nicht so etwas wie eine Adresse, die komplexer ist und sich auf eine Person bezieht, als eigene Entität existieren sollte.

Sie können leicht spezifische Vorgänge für die Adresse ausführen, z. B. die Überprüfung, ob es sich um eine gültige Adresse handelt. Vielleicht wissen Sie das zur Entwurfszeit nicht, aber dieses ganze Konzept besteht darin, Objekte in ihre kleinsten Teile zu zerlegen, so dass so etwas nachträglich relativ einfach ist.

Update: 1) In den meisten Fällen erfolgt diese Identitätsüberprüfung beim Speichern eines Objekts in einem Datenspeicher. Dies bedeutet, dass der Code, der die Entitätsvalidierung darstellt, vorhanden ist, jedoch an anderer Stelle. Es ist normalerweise mit dem Code vorhanden, der für die Ausgabe des Identitätswerts verantwortlich ist. Aus diesem Grund stelle ich fest, dass die Eindeutigkeit nicht direkt im Code für die Entität dargestellt wird.

2) Die richtige Aussage wäre, dass Agees sich um ein Attribut handelt, das Verhalten aufweist. Sie müssen die Tatsache dokumentieren, dass Age faul geladen ist, damit ein Entwickler, der diese Eigenschaft konsumiert, eine genaue Entscheidung darüber treffen kann, wie diese Eigenschaft konsumiert werden soll

3) ist DateOfBirthnormalerweise ein anderes Objekt; Ein Datumsobjekt, für das bereits vordefinierte Vorgänge vorhanden sind. In einigen Sprachen ist auf dem Datumsobjekt bereits ein ganzes Domänenmodell definiert. Beispielsweise können Sie in c # die Zeitzone angeben. Wenn das Datum UTC ist, fügen Sie Daten hinzu und subtrahieren sie, um eine Zeitspanne zu erhalten. Ihre Annahme bezüglich des Umzugs DateOfBirthwäre also richtig.

4) Wenn das Einzige, was getan MyEntitywird, Delegation und Koordination ist, dann verletzt es nicht SRP. Ihre einzige Aufgabe ist die Delegierung und Koordinierung. Sie wird als Fassadenmuster bezeichnet

Sehr gute frage Das SRP sollte nicht ganz so schlicht genommen werden. Die Identifizierung / Suche liegt nicht in der Verantwortung des Unternehmens in Bezug auf die SRP. Jemand anderes ist dafür verantwortlich, ihm eine ID zu geben (nämlich das Geschäft) und nachzuschlagen (nämlich das Repository ).

Der Hauptzweck einer Entität besteht darin, die vom Modell nicht abgedeckten Konzepte darzustellen. Der einzige Unterschied zwischen einer Entität und einem Wertobjekt besteht darin, dass die Entität eine Bedeutung hat, die über ihre nicht identifizierenden Attribute hinausgeht. Wenn zum Beispiel eine Person ihren Namen ändert, ist sie immer noch dieselbe Person, nur mit einem anderen Namen.

Sobald einer Entität eine eindeutige ID zugewiesen wurde, wird ihre Identität festgestellt. Daher würde ich davon ausgehen, dass eine solche Entität kein Verhalten benötigt, um ihre Identität beizubehalten oder sich selbst zu identifizieren. Daher verstehe ich nicht, auf welche Art von Verhalten sich der Autor bezieht (abgesehen von Such- und Abgleichsoperationen) mit "Verhalten, das für das Konzept wesentlich ist"?

Wenn die Identität festgestellt wird, braucht die Entität ja nichts anderes zu identifizieren. Die Verhaltensweisen, auf die sich der Autor bezieht, sind Verhaltensweisen, die der Entität zugeordnet sind. Dies sind die Verhaltensweisen, die den Status der Entität ändern. Beispielsweise kann eine CustomerEntität ein MakePreferredVerhalten aufweisen. Der Grund, warum der Autor vorschlägt, die Entität zu reduzieren, ist, dass beim erstmaligen Erstellen einer CustomerEntität die Tendenz besteht, sie mit allen Attributen zu füllen, von denen man annehmen kann, dass sie einem Kunden zugeordnet sind. Dies ist ein datenzentrierter Ansatz, der Verhaltensweisen übersieht, die letztendlich zu einem anämischen Domänenmodell führen.

In Bezug auf das Verschieben von Verhalten auf andere Objekte bezieht sich der Autor speziell auf Wertobjekte. Der Grund, warum es eine gute Idee ist, das Verhalten auf VOs zu verlagern, ist, dass VOs in der Regel "kleiner" als Entitäten sind und dadurch fokussierter. Darüber hinaus vereinfachen Aspekte wie die Unveränderlichkeit und die Schließung von Vorgängen die Überlegungen zum Code und machen ihn gleichzeitig sicherer .

Zusammen mit VOs dient eine Entität als eine Art Anker, der die verschiedenen VOs koordiniert, die ihr Verhalten implementieren.

In Bezug auf SRP ist Ihre Verwirrung nicht ungerechtfertigt. Ein Problem bei der stereotypen OOP-Implementierung von Entitäten ist die Verschmelzung von Identität und Staat. In der Tat hat Identität aus einer Verhaltensperspektive nichts mit Verhalten zu tun. Mit anderen Worten, die Identität einer Entität ist für keines ihrer Verhaltensweisen erforderlich. Es gibt Implementierungen, bei denen diese Überschneidung beseitigt ist, z. B. AggregateSource oder ein funktionaler Ansatz, den ich hier beschreibe .

Das andere Problem ist, dass SRP in gewissem Maße ein qualitatives Maß sein kann. Jeder kann sich eine Definition der Einzelverantwortung einfallen lassen, gegen die eine Klasse verstößt. Man kann sagen, dass die Verantwortung der Entität darin besteht, die von dieser Entität geforderten Verhaltensweisen umzusetzen. In diesem Sinne hat es eine einzige Verantwortung. Darüber hinaus verletzt eine Entität SRP nicht, wenn sie Verhaltensweisen an konstituierende VOs delegiert. SRP verbietet keine Komposition dieser Art. Es ist Vorsicht geboten, die Kopplung zwischen Objekten auf ein absolutes Minimum zu reduzieren, Schnittstellen so bloß wie möglich zu halten usw.

AKTUALISIEREN

a) Wenn ich Sie richtig verstehe, sagen Sie, dass eine Entität nur solche Verhaltensweisen enthalten soll, die ihre Attribute (dh ihren Zustand) ändern?

Ja, obwohl es Ausnahmen gibt ...

b) Und was ist mit den Verhaltensweisen, die nicht notwendigerweise den Zustand der Entität verändern, aber dennoch als ein wesentliches Merkmal dieser Entität angesehen werden (Beispiel: Bellen wäre ein wesentliches Merkmal einer Entität Hund, selbst wenn dies nicht der Fall wäre Hundestatus ändern)? Sollten wir diese Verhaltensweisen in eine Entität einbeziehen oder sollten sie auf andere Objekte verschoben werden?

Es ist akzeptabel, dass Entitäten Factory-Methoden zum Erstellen von Instanzen von Entitäten enthalten, die effektiv untergeordnete Entitäten sind, bei denen jedoch keine Objektreferenzen zum Durchlaufen verwendet werden. In diesem Fall muss die untergeordnete Entität vom Anwendungsdienst beibehalten werden. Der Anwendungsdienst verwendet die übergeordnete Entität, um die untergeordnete Entität zu erstellen.

3) Unter der Annahme, dass MyEntity (siehe Frage 3 in meinem ursprünglichen Beitrag) SRP nicht verletzt, würden wir sagen, dass eine Verantwortung von MyEntity unter anderem auch Folgendes umfasst:

Sie betrachten die Verantwortung aus der Perspektive der Implementierung. Betrachten Sie die Entität stattdessen als eine Art Black Box mit Verantwortlichkeiten. Wie es damit umgeht, interessiert Sie als Außenstehender nicht. Die Aufteilung der Zuständigkeiten auf VOs oder andere Einheiten ist ein Umsetzungsproblem.

Das Anführungszeichen gibt an, dass nur mit der Identität verknüpfte Attribute in einer Entität verbleiben sollen. Ich gehe davon aus, dass author bedeutet, dass die Entität nur die Attribute enthalten soll, die häufig zum Finden oder Abgleichen dieser Entität verwendet werden, während ALLE anderen Attribute verschoben werden sollen.

Insbesondere sollten Attribute, die für das Verhalten oder Nachschlagen nicht erforderlich sind, nicht Teil der Entität sein. Warum die Mühe? Darüber hinaus benötigen Entitäten mit so etwas wie dem Muster des Lesemodells nichts anderes als Attribute, die für das Verhalten erforderlich sind.

Wenn wir anstelle von Customer.Address (vom Typ string) eine Eigenschaft Customer.Address vom Typ Address erstellen, haben wir das Adressattribut in ein zugehöriges VO-Objekt (vom Typ Address) verschoben, oder würden wir sagen, dass Customer noch eine Adresse enthält Attribut?

Ja, tatsächlich gibt es keinen Unterschied zwischen einer Zeichenfolgenadresse und einer Adresse VO-Adresse.

Ist der Autor hier nicht falsch, da, wenn wir annehmen, dass jede der vielen Kontakttelefonnummern, die der Kunde nur zu diesem bestimmten Kunden gehört, diese Telefonnummern der Identität genauso zugeordnet sind, wie wenn der Kunde sie nur hatte eine Telefonnummer?

Ich bin nicht zu 100% mit der Absicht des Autors einverstanden, aber ich denke, er beschreibt nur, wie die Suchanforderungen für Entitäten die Struktur der Entität und der zugehörigen VOs ändern können.

Ich dachte jedoch, ein anämisches Domänenmodell resultiert aus dem Verschieben von Verhalten aus einer Entität heraus, während Ihr Beispiel eine Entität mit vielen Attributen auffüllt, was dazu führen würde, dass der Kunde zu viel Verhalten hat (da wir wahrscheinlich auch das in Customer einbeziehen würden Verhaltensweisen, die diese zusätzlichen Attribute modifizieren) und damit gegen SRP verstoßen?

Viele Attribute bedeuten nicht viel Verhalten. Tatsächlich schlägt es normalerweise das Gegenteil vor. Viele Attribute mit Gettern und Setzern, aber kein Verkapselungsverhalten.

TL; DR: Sie denken darüber nach. Ich hatte jedoch Spaß daran, es mit dir zu überdenken. Also schnall dich an ....

Die einzige Verantwortung (Grund für eine Änderung) eines Unternehmens sollte darin bestehen, sich eindeutig zu identifizieren, dh seine Verantwortung muss auffindbar sein.

Nein, das stimmt nicht. Die einzige Verantwortung eines Unternehmens ist die Kontinuität.

Identität ist eine aufkommende Konsequenz der Kontinuität. Das Modellieren von Identität als trennbare Idee ist eine Leistungsoptimierung.

Hier ist ein Beispiel: Ein Restaurantpatron gibt dem Parkservice ein Auto. Eine Stunde später fragt ein Gastron nach dem Auto. Sollte der Parkservice es geben?

Es ist leicht zu sagen, dass der Parkservice das Auto geben sollte, wenn der Kunde der "gleiche" ist. Aber was heißt das eigentlich? Der richtige Weg, dies festzustellen, besteht darin, mit dem "Jetzt" -Patron zu beginnen und rückwärts in der Geschichte dieses Patrons zu suchen, um zu sehen, ob die Übergabe des Autos an den Parkservice Teil dieser Geschichte ist.

Das können wir natürlich nicht. Es fällt uns schwer, unsere eigene Geschichte genau zu verfolgen, egal, was die ganze Zeit über nicht bei uns war. Anstatt die Benutzerhistorie zu verwenden, verwenden wir Abkürzungen. Besitzt der Benutzer den Ticket-Stub, der dieselbe Nummer hat wie der Tag, der gerade mit den Schlüsseln verbunden ist? Entspricht der Führerschein in der Brieftasche des Benutzers dem Namen auf dem Titel des DMV, ähnelt das Bild auf dem Führerschein dem Gesicht des Benutzers? Etc.

Kurz gesagt: Anstatt den Verlauf des Benutzers zu überprüfen, überprüfen wir den aktuellen Status des Benutzers, um festzustellen, ob der aktuelle Status mit einem Verlauf übereinstimmt, der den Zeitraum zwischen dem Eintreffen des Fahrzeugs und der Anforderung seiner Rückgabe abdeckt.

Bei der Modellierung von Objekten verwenden wir eine analoge Optimierung. Wir geben allen Unternehmen die gemeinsame Verantwortung von

1. Sicherstellen, dass der Beginn des Verlaufs die Zuweisung einer unveränderlichen Kennung zum Status des Objekts enthält
2. Sicherstellen, dass der nächste Status immer eine originalgetreue Kopie des Bezeichners des vorherigen Status enthält.

Ich beschreibe hier keine zweite Verantwortung der Entität; Das Unternehmen ist nach wie vor für die Kontinuität verantwortlich und stellt sicher, dass die Geschichte eine konsistente Darstellung ist. Die Identifikatorverantwortlichkeiten sind nur eine Teilmenge, die allen Entitäten gemeinsam ist.

Wir haben noch keine Durchsetzung der Einzigartigkeit. Dies ist in einer einzelnen Entität nicht möglich, da für die Eindeutigkeit der Zugriff auf den Status aller Entitäten erforderlich ist. wobei eine einzelne Entität nur Zugriff auf ihre eigene hat.

Auch hier ist es nicht praktikabel, alle Kennungen jedes Mal zu überprüfen. Stattdessen stellen wir die Eindeutigkeit auf einfache Weise sicher: Der Code, der die nächste Kennung generiert, darf sich nie wiederholen.

Am Ende bedeutet dies, dass wir die Kontinuität überprüfen können, indem wir die Äquivalenz von zwei verschiedenen Zustandselementen im Speicher testen. Dies erspart den Versuch, azyklische Graphen abzufragen, erheblich.

Sie scheinen auch das Prinzip der Einzelverantwortung (was eine wirklich gute Idee ist) mit einem Prinzip der atomaren Verantwortung verwechselt zu haben. Die Aufteilung einer Verantwortung in kleinere, einfacher zu verwaltende Teile ist mit SRP kompatibel.

Nun, es hängt davon ab, wie Sie es betrachten möchten.

Ein anderer Weg ist: "Verstößt das Prinzip der Einzelverantwortung gegen die Domänenentität?"

Beides sind Richtlinien. Es gibt kein "Prinzip" im Software-Design. Es gibt jedoch gute und schlechte Designs. Beide Konzepte können auf unterschiedliche Weise verwendet werden, um ein gutes Design zu erzielen.