Wie ein einzelnes Verantwortungsprinzip auf ein anämisches/reiches Domänenmodell bezieht?

Question

Derzeit habe ich eine Code -Überprüfung von Sachen durch ein anderes Team durchführen und einen Zweifel an der Anwendung von SRP und seiner Beziehung zum anämischen oder reichen Domänenmodell (wie von Martin Fowler definiert) anwenden. Das Rich Domain -Modellkonzept besteht darin, intelligentes Objekt zu haben, das nicht nur ihre Eigenschaften festlegen/abrufen kann, sondern auch eine kompliziertere Geschäftslogik ausführen kann. Ich wünschte, wie es in SRP passt?

Sagen Sie, ich habe meine Modellklasse mit einigen Eigenschaften, die diese Requisiten freilegen und einige einfache Berechnungen für die Verantwortlichen bereitstellen können. Die nächste Anforderung besteht darin, diese Objektdaten in einem Speicherobjekt zu speichern, das nicht unter meiner Kontrolle steht, wie folgt:

class MyObject {
    // get set
    // parse sth

}

Speichern Sie die Methode im Speicher

   storage.store(key, object);

Verletzt es nicht SRP, wenn MyObject solche Speichermethode hat

public void store(Storage storage) {
    storage.store('keyOne', fieldOne);
    storage.store('keyTwo', fieldTwo);
}

Aus dem POV dieses Objekts ist es ein guter Gedanke, seinen Zustand aufbewahren zu können. Andere Möglichkeiten könnten darin bestehen, hier eine Art Service einzuführen und dies so zu tun:

public StorageService {
    private Storage;
    // constructor here
    ....
    public void store(MyObject myobj);
}

Können Sie mir Links verweisen, die ich über dieses Problem lesen kann? Ich habe hier einen Thread gefunden, aber es beantwortet meine Frage nicht vollständig.

Wie wird es in DDD gelöst? Modelle in DDD sind per Definition reich und können zu viele Verantwortlichkeiten haben.

Answer 1

Ein reiches Domänenmodell (RDM) bedeutet, dass die Logik das Modell des Modells regieren Verhalten gehört zu dem Modell, anstatt das Modell wie Daten mit Gettern/Setzern zu behandeln. Das macht nicht bedeuten alles, einschließlich Persistenz, Sicherheit, wie das Modell in der GUI usw. angezeigt wird.

RDM und SRP gehen Hand in Hand, sie widersprechen nicht miteinander.

Verstoß gegen SRP/RDM:

Car {
   // possibly violates SRP
   storeInDatabase();  
   // smells like anemic domain model
   getEngineState();   
}

Folgt SRP/RDM:

// usings aspects to remove cross-cutting concerns from the model and follow SRP
@DatabaseSerializable 
Car {
   // rich domain model encapsulates engine state and exposes behavior
   drive();            
}

Answer 2

"Modelle in DDD sind per Definition reich und können zu viele Verantwortlichkeiten haben." ist eine vereinfachte Interpretation von DDD. Immer hängt es davon ab, wie gut Ihre Modelle sind. Mit DDD können Sie schlechte Modelle erstellen (z. B. Erstellen von Objekten mit zu vielen Verantwortlichkeiten oder erstellen anämischer Modelle). DDD und SRP sind ebenfalls zwei gute Praktiken, die ebenso wie Refactoring, TDD und vieles mehr folgen, aber Sie sollten ihre Verwendung mit Ihrer Erfahrung und Ihrem Urteil (oder dem eines anderen) ergänzen. Alles hat seine Vor- und Nachteile. Seien Sie nicht dogmatisch, wenn Sie keine Praxis anwenden.

Answer 3

@Garrett Hall

Ich bin mit Ihrer Aussage "RDM und SRP Hand in Hand, sie stehen nicht miteinander in Konflikt." Nach meiner Erfahrung führt es, wenn SRP überbetont wird, zu einem anämischen Domänenmodell. "Nein, wir können keine Beharrlichkeit tun oder sogar helfen, nicht einmal zu wissen, was eine GUI ist ..." und Ihre Klasse tue nicht einmal nichts und habe nur ein anämisches Domänenmodell.

Und wenn RDM überbetont wird (das ist die Richtung/Fehler, in die ich tendiere), dann hält SRP vollständig auf der Strecke und Sie bemerken schließlich, dass Ihre Klasse 100er -Methoden hat und eindeutig zu viel tut.

Sie müssen ein Gleichgewicht finden, das glückliche Medium, in dem sowohl RDM als auch SRP stattfinden. Und das Finden dieses Gleichgewichts ist schwierig und beinhaltet oft mehr Darmgefühle und Politik in Ihrem Team als technische Verblicke oder Regeln.

"Weißt du dich selbst". Wenn Sie wie ich sind und zu übermäßig komplexen Klassen tendieren, seien Sie sich bewusst. Und wenn Sie die Klasse eines anderen sehen, der für Sie zu komplex aussieht, ist das eine große rote Fahne. Wenn Sie wissen, dass Sie in Bezug auf SRP ziemlich hart sind und eine Klasse sehen, die auch nach Ihren Maßstäben anämisch aussieht, ist dies ein großer Codegeruch.

Wenn ich jetzt die Frage des OP zum Speicher beantwortet habe, hängt ich viel davon ab, wie stabil, Standard und abstrakter Speicher sind. Wenn Speicher einige Standard -XML-, CSV- oder RDB -Abstraktion darstellt, habe ich absolut kein Problem mit Objekten, die wissen, wie man sich speichert.