Best Practices für die Serialisierung von DDD-Aggregaten

Laut DDD sollte die Domänenlogik nicht mit technischen Problemen wie Serialisierung, objektrelationaler Zuordnung usw. verschmutzt werden.

Wie können Sie also den Aggregatzustand serialisieren oder zuordnen, ohne ihn öffentlich über Getter und Setter verfügbar zu machen? Ich habe viele Beispiele für z. B. Repository-Implementierungen gesehen, aber praktisch alle stützten sich bei der Zuordnung auf öffentliche Zugriffsmethoden für die Entitäten und Wertobjekte.

Wir könnten Reflektion verwenden, um öffentliche Zugriffsmethoden zu vermeiden, aber IMO wären diese Domänenobjekte implizit immer noch vom Serialisierungsproblem abhängig. Sie konnten z. B. ein privates Feld nicht umbenennen oder entfernen, ohne Ihre Serialisierungs- / Zuordnungskonfiguration zu optimieren. Sie müssen also eine Serialisierung in Betracht ziehen, bei der Sie sich stattdessen auf die Domänenlogik konzentrieren sollten.

Also, was ist der beste Kompromiss, um hier zu folgen? Lebe mit öffentlichen Accessoren, aber vermeide es, sie für etwas anderes als das Zuordnen von Code zu verwenden? Oder habe ich nur etwas Offensichtliches verpasst?

Ich bin ausdrücklich daran interessiert, den Status von DDD-Domänenobjekten (Aggregate, die aus Entitäten und Wertobjekten bestehen) zu serialisieren. Hier geht es NICHT um die Serialisierung in allgemeinen oder Transkationsskriptszenarien , in denen zustandslose Dienste für einfache Datencontainerobjekte ausgeführt werden.

Arten von Objekten

Lassen Sie uns zu Zwecken unserer Diskussion unsere Objekte in drei verschiedene Arten unterteilen:

Geschäftsbereichslogik

Dies sind die Objekte, die die Arbeit erledigen. Sie transferieren Geld von einem Girokonto auf ein anderes, erfüllen Aufträge und alle anderen Aktionen , die von Unternehmenssoftware erwartet werden.

Domänenlogikobjekte erfordern normalerweise keine Accessoren (Getter und Setter). Stattdessen erstellen Sie das Objekt, indem Sie die Abhängigkeiten über einen Konstruktor übergeben und das Objekt dann über Methoden bearbeiten (Tell, Don't Ask).

Datenübertragungsobjekte

Datenübertragungsobjekte sind reine Zustände. Sie enthalten keine Geschäftslogik. Sie werden immer Accessoren haben. Sie können Setter haben oder auch nicht, je nachdem, ob Sie sie unveränderlich schreiben oder nicht . Sie werden entweder Ihre Felder im Konstruktor festlegen und deren Werte werden sich während der Lebensdauer des Objekts nicht ändern, oder Ihre Zugriffsmethoden werden gelesen / geschrieben. In der Praxis sind diese Objekte normalerweise veränderbar, sodass ein Benutzer sie bearbeiten kann.

Modellobjekte anzeigen

Ansichtsmodellobjekte enthalten eine anzeigbare / bearbeitbare Datendarstellung. Sie können Geschäftslogik enthalten, die normalerweise auf die Datenüberprüfung beschränkt ist. Ein Beispiel für ein View Model-Objekt kann ein InvoiceViewModel sein, das ein Customer-Objekt, ein Invoice Header-Objekt und Rechnungsposten enthält. View Model-Objekte enthalten immer Accessoren.

Die einzige Art von Objekt, die in dem Sinne "rein" ist, dass sie keine Feldzugriffsmethoden enthält, ist das Domain Logic-Objekt. Durch die Serialisierung eines solchen Objekts wird sein aktueller "Berechnungsstatus" gespeichert, sodass er später abgerufen werden kann, um die Verarbeitung abzuschließen. Ansichtsmodelle und DTOs können frei serialisiert werden, aber in der Praxis werden ihre Daten normalerweise in einer Datenbank gespeichert.

Serialisierung, Abhängigkeiten und Kopplung

Zwar entstehen durch die Serialisierung Abhängigkeiten in dem Sinne, dass Sie eine Deserialisierung für ein kompatibles Objekt durchführen müssen, doch müssen Sie die Serialisierungskonfiguration nicht unbedingt ändern. Gute Serialisierungsmechanismen sind allgemeine Zwecke. Es ist ihnen egal, ob Sie den Namen einer Eigenschaft oder eines Mitglieds ändern, solange sie den Mitgliedern noch Werte zuordnen können. In der Praxis bedeutet dies nur, dass Sie die Objektinstanz erneut serialisieren müssen, um die Serialisierungsdarstellung (xml, json usw.) mit Ihrem neuen Objekt kompatibel zu machen. Es sollten keine Konfigurationsänderungen am Serializer erforderlich sein.

Es ist richtig, dass sich Objekte nicht damit befassen sollten, wie sie serialisiert werden. Sie haben bereits eine Möglichkeit beschrieben, wie solche Bedenken von den Domänenklassen abgekoppelt werden können: Reflexion. Der Serialisierer sollte sich jedoch Gedanken darüber machen, wie er Objekte serialisiert und deserialisiert. das ist schließlich seine Funktion. Sie können Ihre Objekte vom Serialisierungsprozess entkoppeln, indem Sie die Serialisierung zu einer Allzweckfunktion machen , die für alle Objekttypen geeignet ist .

Verwirrung stiftet unter anderem, dass die Entkopplung in beide Richtungen erfolgen muss. Es tut nicht; es muss nur in eine richtung funktionieren . In der Praxis kann man sich niemals vollständig entkoppeln. es gibt immer eine Kopplung. Das Ziel der losen Kopplung besteht darin, die Pflege des Codes zu vereinfachen und nicht alle Abhängigkeiten zu beseitigen.

Der eigentliche Zweck der Serialisierung besteht darin, sicherzustellen, dass die von einem System erzeugten Daten von einem oder mehreren kompatiblen Systemen verarbeitet werden können.

Der einfachste und robusteste Ansatz für die Serialisierung besteht darin, die Daten in ein typunabhängiges Format zu übersetzen, das die Struktur in einem einfachen und benutzerfreundlichen Format beibehält. Beispielsweise verwenden die am weitesten verbreiteten Serialisierungsformate (z. B. JSON, XML) ein genau definiertes textbasiertes Format. Text ist einfach zu produzieren, zu übertragen und zu konsumieren.

Es gibt zwei Gründe, warum die Verwendung eines dieser Formate möglicherweise nicht ideal ist.

1. Effizienz

   Die Übersetzung aller Daten in ihre textbasierten Entsprechungen ist mit Kosten verbunden. Datentypen gäbe es nicht, wenn Text die effizienteste Möglichkeit wäre, die verschiedenen Datenformen auszudrücken. Darüber hinaus ist die Struktur dieser Formate nicht ideal, um Teilmengen von Daten asynchron oder in Teilen abzurufen.

   XML und JSON gehen beispielsweise davon aus, dass die verwendeten Daten von Anfang bis Ende geschrieben und gelesen werden. Für die Verarbeitung sehr großer Datenmengen, in denen der Speicher knapp ist, kann es erforderlich sein, dass das System, das die Daten verbraucht, die Daten in Teilen verarbeiten kann. In diesem Fall ist möglicherweise eine spezielle Serialisierungs- / Deserialisierungsimplementierung erforderlich, um die Daten zu verarbeiten.

2. Präzision

   Das Casting, das zum Serialisieren / Deserialisieren der Daten vom beabsichtigten Typ zum datenunabhängigen Typ erforderlich ist, führt zu einem Genauigkeitsverlust.

Man könnte argumentieren, dass das Erzeugen einer binären Darstellung der Objekte und Daten eindeutig die effizienteste und genaueste Lösung ist. Der Hauptnachteil ist, dass die Implementierung aller Systeme, die Daten verbrauchen und produzieren, kompatibel bleiben muss. In der Theorie ist dies eine einfache Einschränkung, in der Praxis jedoch ein Albtraum, da sich Produktionssysteme im Laufe der Zeit ändern bzw. weiterentwickeln.

Nachdem das gesagt worden ist. Das Entkoppeln der Serialisierung / Deserialisierung von den domänenspezifischen Details ist in der Regel sinnvoll, da Allzweckformate robuster sind, über verschiedene Systeme hinweg besser unterstützt werden und nur einen geringen bis keinen erhöhten Wartungsaufwand erfordern.