database - ¿Cómo utilizar actores para el acceso a bases de datos y DDD?
scala concurrency (1)
No estoy muy seguro de cómo se pueden usar los actores para acceder a la base de datos. En la documentación y los libros para Akka este tema parece omitirse.
Una solución puede ser un DAO envuelto en un actor sin estado. Por ejemplo, para cada tabla (o tipo de objeto de dominio o agregado) en la base de datos, se puede crear un actor responsable de todas las operaciones de CRUD. Una variación de esto puede ser una separación de comandos y consultas. Por ejemplo, para cada actor de comando de tipo de datos 1 (para concurrencia) y 10 actores de consulta (para paralelismo).
Otro enfoque podría ser crear actores con estado que representen exactamente una fila (o instancia de objeto de dominio o instancia agregada) en la base de datos. Por supuesto, la base de datos también puede ser en este caso un almacén de eventos (como el módulo de persistencia akka) con una proyección eventualmente consistente a una base de datos, un almacén de documentos o un caché. Eso no es relevante aquí. Este enfoque es en realidad una implementación de un caché en memoria con todos los beneficios y problemas. Debe haber una estrategia para destruir a los actores para no quedarse sin memoria después de un tiempo.
Extenderé mi pregunta para DDD:
Digamos, quiero desarrollar una aplicación DDD con actores Akka. Concentrémonos aquí en la parte de comando. En mi opinión, esto debería implementarse de esta manera: para cada contexto acotado habrá un actor de puerto, por ejemplo, la API REST de Spray, que enruta los mensajes al actor de servicio de dominio apropiado. Este actor de servicio coordina una tarea de negocio a uno o más agregados de modelo de dominio. Cada agregado único es un actor con estado que el actor de servicio restaura (o crea en nuevos datos) desde la base de datos. El actor de servicio envía / enruta mensajes a todos los actores agregados involucrados. Los actores del modelo de dominio receptor realizarán la validación comercial en su mensaje de estado + y luego escribirán sus cambios en la base de datos, por ejemplo, DAOs Slick. Después de enviar una copia al agente de servicio, se detienen. Cuando todos los actores agregados han finalizado, se envía un mensaje finalizado al remitente del mensaje. Una variación podría ser no detener a los actores del modelo de dominio con estado de forma inmediata, pero después de un período de tiempo, digamos 3 minutos.
¿Es este un patrón de uso válido para DDD con Akka?
Generalmente, las operaciones de lectura de DB (cRud) pueden ser realizadas directamente por cualquier actor. No hay necesidad de hacer ningún manejo especial en la mayoría de los casos. Solo un simple round-robin para equilibrar la carga.
En cuanto a las operaciones de actualización (CrUD), se pueden dividir en dominios / fragmentos que no se intersectan. Por ejemplo, todas las operaciones con una sola cuenta deben ser procesadas preferiblemente por un solo actor. Uno puede tener N actores de procesamiento casi independientes y un enrutador que enruta los comandos a uno de ellos basado en account.hashCode% N, por ejemplo. De este modo, las operaciones se distribuirán entre los actores de manera más o menos equitativa y cada cuenta se procesará secuencialmente.
PS Slick parece ser una biblioteca de bases de datos de descenso para aplicaciones Akka.