Was passiert, wenn OOP auf die reale Welt™ trifft

Der Autor hinterfragt die Anwendung objektorientierter Designprinzipien, insbesondere die der Kapselung, in komplexen Szenarien wie der Duplizierung und Versionierung von Objekten. Er erkennt die Bedeutung, Daten und Verhalten zusammenzuhalten, hat aber Schwierigkeiten, zu entscheiden, welches Objekt wissen sollte, wie bestimmte Aktionen auszuführen sind. Der Autor gibt ein Beispiel für ein Eltern-Kind-Modell, in dem die Eltern die Duplizierung verschachtelter Datensätze orchestrieren sollten. Dies wirft die Frage auf, wo Orchestrierungslogik, die sich über mehrere Objekte erstreckt, platziert werden soll. Es werden drei Optionen vorgestellt: die Verwendung eines Orchestrators oder Service-Objekt-Musters, die Zuweisung der Verantwortung an das Aggregat-Root oder die Delegation der Duplizierung an das verschachtelte Objekt. Jede Option hat Vor- und Nachteile, wie z. B. die Auslagerung von Orchestrierungslogik aus Domänenmodellen versus die Anhäufung von Koordinationslogik im Aggregat-Root. Der Autor kommt zu dem Schluss, dass Kapselung zwar wertvoll ist, aber kontextuelle Verhaltensweisen wie Versionierung und Duplizierung nicht immer in Domänenobjekte gehören. Diese Verhaltensweisen sind zeitlich, objektübergreifend und erfordern möglicherweise Wissen, das das Objekt nicht haben sollte. Die Lösung liegt darin, neu zu definieren, welcher Wissenskontext und welches Objekt am besten geeignet sind, um gekapselt zu werden. Dieser Ansatz erkennt an, dass Domänenentitäten Zustände und Invarianten modellieren, nicht jeden prozeduralen Ablauf, und ist kein Verrat an objektorientierten Prinzipien.