Ich bin mir nicht ganz sicher, wie man mit Schauspielern auf die Datenbank zugreifen kann. In der Dokumentation und den Büchern zu Akka scheint dieses Thema ausgelassen zu sein.Wie verwenden Sie Akteure für den Datenbankzugriff und DDD?
Eine Lösung kann ein eingehülltes DAO in einem staatenlosen Akteur sein. Zum Beispiel kann für jede Tabelle (oder Domänenobjekttyp oder Aggregattyp) in der Datenbank ein Akteur erstellt werden, der für alle CRUD-Operationen verantwortlich ist. Eine Variation davon kann eine Trennung von Befehlen und Abfragen sein. Zum Beispiel für jeden Befehlstyp des Datentyps 1 (für Parallelität) und 10 Abfrageaktoren (für Parallelität).
Ein anderer Ansatz könnte darin bestehen, statusabhängige Aktoren zu erstellen, die genau eine Zeile (oder Domänenobjektinstanz oder Aggregat-Instanz) in der Datenbank repräsentieren. Natürlich kann die Datenbank in diesem Fall auch ein Ereignisspeicher (wie das Akka-Persistenzmodul) mit einer eventuell konsistenten Projektion auf eine Datenbank, einen Dokumentenspeicher oder einen Cache sein. Das ist hier nicht relevant. Dieser Ansatz ist eigentlich eine Implementierung eines Cache im Speicher mit allen Vorteilen und Problemen. Es muss eine Strategie geben, um Akteure zu zerstören, um nicht nach einer Weile den Speicher zu verlieren.
Ich werde meine Frage für DDD erweitern:
Lassen Sie uns sagen, ich möchte eine DDD-Anwendung mit Akka Akteuren entwickeln. Konzentrieren wir uns hier auf den Befehlsteil. Meiner Meinung nach sollte dies auf diese Weise implementiert werden: Für jeden begrenzten Kontext wird ein Port-Aktor, z.B. REST-API sprühen, die Nachrichten an den entsprechenden Domänen-Service-Actor weiterleitet. Dieser Dienstaktor koordiniert eine Geschäftsaufgabe mit einem oder mehreren Domänenmodellaggregaten. Jedes einzelne Aggregat ist ein zustandsbehafteter Akteur, der vom Dienstakteur aus der Datenbank wiederhergestellt (oder auf neuen Daten erstellt) wird. Der Dienstakteur sendet/leitet Nachrichten an alle beteiligten aggregierten Akteure. Die empfangenden Domänenmodell-Akteure führen eine Geschäftsvalidierung für ihre Statusnachricht durch und schreiben dann ihre Änderungen in die Datenbank, z. Slick DAOs. Nach dem Senden einer done zurück zum Service-Actor werden sie gestoppt. Wenn alle aggregierten Akteure fertig sind, wird eine Nachricht an den Absender der Nachricht zurückgeschickt. Eine Variation könnte darin bestehen, die zustandsbehafteten Domänenmodell-Akteure nicht sofort zu stoppen, sondern nach einer Zeitspanne von beispielsweise 3 Minuten.
Ist dies ein gültiges Verwendungsmuster für DDD mit Akka?
Ich verstehe nicht, warum das enge Stimmen bekommt. Ich habe auch immer herausgefunden, dass Datenzugriffe ein dunstiges/nicht gut dokumentiertes Thema in Actor Model-Plattformen sind. Ich denke (aber nicht getestet), dass ein Event-Sourcing-Ansatz gut mit dem Akteur des Schauspielers harmonieren würde, da Akteursnachrichten unveränderlich sind. Ein Aggregat würde eine Nachricht an die Welt senden (d. H. Einen absendenden Aktor), die ihren neuen Zustand enthält. Dann wäre ein Persistenz-Akteur dafür verantwortlich, diesen neuen Zustand dem Ereignisspeicher anzuhängen. Andere Akteure könnten basierend auf dieser Nachricht auf Ad-hoc-Basis handeln. – guillaume31
Event Sourcing ist eigentlich schon eine eingebaute Funktion in Akka. Ich habe es noch nicht getestet, weil ich neu bei Akka bin und es ein Komplexitätsverstärker für mich ist. Siehe http://doc.akka.io/docs/akka/snapshot/scala/persistenz.html – Sebastian
Zu meiner Zukunft ich: Denken Sie daran, das Buch zu lesen * Reactive Enterprise mit Schauspieler Modell: Anwendung und Integration Patterns für Scala und Akka * von ** Vaughn Vernon ** Frühling 2015 [Amazon] (http://www.amazon.co .uk/dp/0133846830 /) – Sebastian